ON THIS PAGE
ITU-T Y.1731 Ethernet Service OAM Overview
SUMMARY This section describes service OAM (ITU-TY.1731) and its two main components: fault management (monitoring, detection, and isolation) and performance monitoring (frame loss measurement, synthetic frame loss measurement, and frame delay measurement).
Ethernet Frame Delay Measurements Overview
- ITU-T Y.1731 Frame Delay Measurement Feature
- One-Way Ethernet Frame Delay Measurement
- Two-Way Ethernet Frame Delay Measurement
- Choosing Between One-Way and Two-Way ETH-DM
- Restrictions for Ethernet Frame Delay Measurement
ITU-T Y.1731 Frame Delay Measurement Feature
The IEEE 802.3-2005 standard for Ethernet Operations, Administration, and Maintenance (OAM) defines a set of link fault management mechanisms to detect and report link faults on a single point-to-point Ethernet LAN.
Junos OS supports key OAM standards that provide for automated end-to-end management and monitoring of Ethernet service by service providers:
IEEE Standard 802.1ag, also known as “Connectivity Fault Management (CFM).”
ITU-T Recommendation Y.1731, which uses different terminology than IEEE 802.1ag and defines Ethernet service OAM features for fault monitoring, diagnostics, and performance monitoring.
These capabilities allow operators to offer binding service-level agreements (SLAs) and generate new revenues from rate- and performance-guaranteed service packages that are tailored to the specific needs of their customers.
ACX Series routers support proactive and on-demand modes.
You can configure ITU-T Y.1731 standard-compliant Ethernet loss measurement (ETH-LM), Ethernet synthetic loss measurement (ETH-SLM), and Ethernet delay measurement (ETH- DM) capabilities on MPC10 and MPC11 line cards on 20.2R2-S3 only and 20.4R1 onwards.
ACX5048 and ACX5096 routers supports only software-based time stamping for delay measurement.
Ethernet CFM
The IEEE 802.1ag standard for connectivity fault management (CFM) defines mechanisms to provide for end-to-end Ethernet service assurance over any path, whether a single link or multiple links spanning networks composed of multiple LANs.
For Ethernet interfaces on M320, MX Series, and T Series routers, Junos OS supports the following key elements of the Ethernet CFM standard:
Fault monitoring using the IEEE 802.1ag Ethernet OAM Continuity Check protocol
Path discovery and fault verification using the IEEE 802.1ag Ethernet OAM Linktrace protocol
Fault isolation using the IEEE 802.1ag Ethernet OAM Loopback protocol
In a CFM environment, network entities such as network operators, service providers, and customers may be part of different administrative domains. Each administrative domain is mapped into one maintenance domain. Maintenance domains are configured with different level values to keep them separate. Each domain provides enough information for the entities to perform their own management and end-to-end monitoring, and still avoid security breaches.
Figure 1 shows the relationships among the customer, provider, and operator Ethernet bridges, maintenance domains, maintenance association end points (MEPs), and maintenance intermediate points (MIPs).
On ACX Series routers, the maintenance intermediate points (MIP) is supported only on the ACX5048 and ACX5096 routers.
Ethernet Frame Delay Measurement
Two key objectives of OAM functionality are to measure quality-of-service attributes such as frame delay and frame delay variation (also known as “frame jitter”). Such measurements can enable you to identify network problems before customers are impacted by network defects.
Junos OS supports Ethernet frame delay measurement between MEPs configured on Ethernet physical or logical interfaces on MX Series routers. 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. The Junos OS implementation of Ethernet frame delay measurement (ETH-DM) is fully compliant with the ITU-T Recommendation Y.1731, OAM Functions and Mechanisms for Ethernet-based Networks. The recommendation defines OAM mechanisms for operating and maintaining the network at the Ethernet service layer, which is called the "ETH layer" in ITU-T terminology.
MX Series routers with modular port concentrators (MPCs) and 10-Gigabit Ethernet MPCs with SFP+ support ITU-T Y.1731 functionality on VPLS for frame-delay and delay-variation.
MX Series Virtual Chassis does not support Ethernet frame delay measurement (DM).
One-Way Ethernet Frame Delay Measurement
In one-way ETH-DM mode, a series of frame delay and frame delay variation values are calculated based on the time elapsed between the time a measurement frame is sent from the initiator MEP at one router and the time when the frame is received at the receiver MEP at the other router.
ACX Series routers do not support one-way Ethernet frame delay measurement.
- 1DM Transmission
- 1DM Reception
- One-Way ETH-DM Statistics
- One-Way ETH-DM Frame Counts
- Synchronization of System Clocks
1DM Transmission
When you start a one-way frame delay measurement, the router sends 1DM frames—frames that carry the protocol data unit (PDU) for a one-way delay measurement—from the initiator MEP to the receiver MEP at the rate and for the number of frames you specify. The router marks each 1DM frame as drop-ineligible and inserts a timestamp of the transmission time into the frame.
1DM Reception
When an MEP receives a 1DM frame, the router that contains the receiver MEP measures the one-way delay for that frame (the difference between the time the frame was received and the timestamp contained in the frame itself) and the delay variation (the difference between the current and previous delay values).
One-Way ETH-DM Statistics
The router that contains the receiver MEP stores each set of one-way delay statistics in the ETH-DM database. The ETH-DM database collects up to 100 sets of statistics for any given CFM session (pair of peer MEPs). You can access these statistics at any time by displaying the ETH-DM database contents.
One-Way ETH-DM Frame Counts
Each router counts the number of one-way ETH-DM frames sent and received:
For an initiator MEP, the router counts the number of 1DM frames sent.
For a receiver MEP, the router counts the number of valid 1DM frames received and the number of invalid 1DM frames received.
Each router stores ETH-DM frame counts in the CFM database. The CFM database stores CFM session statistics and, for interfaces that support ETH-DM, any ETH-DM frame counts. You can access the frame counts at any time by displaying CFM database information for Ethernet interfaces assigned to MEPs or for MEPs in CFM sessions.
Synchronization of System Clocks
The accuracy of one-way delay calculations depends on close synchronization of the system clocks at the initiator MEP and receiver MEP.
The accuracy of one-way delay variation is not dependent on system clock synchronization. Because delay variation is simply the difference between consecutive one-way delay values, the out-of-phase period is eliminated from the frame jitter values.
For a given one-way Ethernet frame delay measurement, frame delay and frame delay variation values are available only on the router that contains the receiver MEP.
Two-Way Ethernet Frame Delay Measurement
In two-way ETH-DM mode, frame delay and frame delay variation values are based on the time difference between when the initiator MEP transmits a request frame and receives a reply frame from the responder MEP, subtracting the time elapsed at the responder MEP.
- DMM Transmission
- DMR Transmission
- DMR Reception
- Two-Way ETH-DM Statistics
- Two-Way ETH-DM Frame Counts
DMM Transmission
When you start a two-way frame delay measurement, the router sends delay measurement message (DMM) frames— frames that carry the PDU for a two-way ETH-DM request—from the initiator MEP to the responder MEP at the rate and for the number of frames you specify. The router marks each DMM frame as drop-ineligible and inserts a timestamp of the transmission time into the frame.
DMR Transmission
When an MEP receives a DMM frame, the responder MEP responds with a delay measurement reply (DMR) frame, which carries ETH-DM reply information and a copy of the timestamp contained in the DMM frame.
DMR Reception
When an MEP receives a valid DMR, the router that contains the MEP measures the two-way delay for that frame based on the following sequence of timestamps:
TITxDMM
TRRxDMM
TRTxDMR
TIRxDMR
A two-way frame delay is calculated as follows:
[TIRxDMR – TITxDMM] – [TRTxDMR – TRRxDMM]
The calculation show that frame delay is the difference between the time at which the initiator MEP sends a DMM frame and the time at which the initiator MEP receives the associated DMR frame from the responder MEP, minus the time elapsed at the responder MEP.
The delay variation is the difference between the current and previous delay values.
Two-Way ETH-DM Statistics
The router that contains the initiator MEP stores each set of two-way delay statistics in the ETH-DM database. The ETH-DM database collects up to 100 sets of statistics for any given CFM session (pair of peer MEPs). You can access these statistics at any time by displaying the ETH-DM database contents.
Two-Way ETH-DM Frame Counts
Each router counts the number of two-way ETH-DM frames sent and received:
For an initiator MEP, the router counts the number DMM frames transmitted, the number of valid DMR frames received, and the number of invalid DMR frames received.
For a responder MEP, the router counts the number of DMR frames sent.
Each router stores ETH-DM frame counts in the CFM database. The CFM database stores CFM session statistics and, for interfaces that support ETH-DM, any ETH-DM frame counts. You can access the frame counts at any time by displaying CFM database information for Ethernet interfaces assigned to MEPs or for MEPs in CFM sessions.
For a given two-way Ethernet frame delay measurement, frame delay and frame delay variation values are available only at the router that contains the initiator MEP.
Choosing Between One-Way and Two-Way ETH-DM
One-way frame delay measurement requires that the system clocks at the initiator MEP and receiver MEP are closely synchronized. Two-way frame delay measurement does not require synchronization of the two systems. If it is not practical for the clocks to be synchronized, two-way frame delay measurements are more accurate.
When two systems are physically close to each other, their one-way delay values are very high compared to their two-way delay values. One-way delay measurement requires that the timing for the two systems be synchronized at a very granular level, and MX Series routers currently do not support this granular synchronization.
Restrictions for Ethernet Frame Delay Measurement
The following restrictions apply to the Ethernet frame delay measurement feature:
The ETH-DM feature is not supported on label-switched interface (LSI) pseudowires.
The ETH-DM feature is supported on aggregated Ethernet interfaces.
Hardware-assisted timestamping for ETH-DM frames in the reception path is only supported for MEP interfaces on Enhanced DPCs and Enhanced Queuing DPCs in MX Series routers. For information about hardware-assisted timestamping, see Guidelines for Configuring Routers to Support an ETH-DM Session and Enabling the Hardware-Assisted Timestamping Option.
Ethernet frame delay measurements can be triggered only when the distributed periodic packet management daemon (
ppm) is enabled. For more information about this limitation, see Guidelines for Configuring Routers to Support an ETH-DM Session and Ensuring That Distributed ppm Is Not Disabled.You can monitor only one session at a time to the same remote MEP or MAC address. For more information about starting an ETH-DM session, see Starting an ETH-DM Session.
ETH-DM statistics are collected at only one of the two peer routers in the ETH-DM session. For a one-way ETH-DM session, you can display frame ETH-DM statistics at the receiver MEP only, using ETH-DM-specific
showcommands. For a two-way ETH-DM session, you can display frame delay statistics at the initiator MEP only, using the same ETH-DM-specificshowcommands. For more information, see Managing ETH-DM Statistics and ETH-DM Frame Counts.ETH-DM frame counts are collected at both MEPs and are stored in the respective CFM databases.
If graceful Routing Engine switchover (GRES) occurs, any collected ETH-DM statistics are lost, and ETH-DM frame counts are reset to zeroes. Therefore, the collection of ETH-DM statistics and ETH-DM frame counters has to be restarted, after the switchover is complete. GRES enables a router with dual Routing Engines to switch from a primary Routing Engine to a backup Routing Engine without interruption to packet forwarding. For more information, see the Junos OS High Availability User Guide.
Accuracy of frame delay statistics is compromised when the system is changing (such as from reconfiguration). We recommend performing Ethernet frame delay measurements on a stable system.
Ethernet Frame Loss Measurement Overview
The key objectives of the OAM functionality are to measure quality-of-service attributes such as frame delay, frame delay variation (also known as “frame jitter”), and frame loss. Such measurements enable you to identify network problems before customers are impacted by network defects.
Junos OS supports Ethernet frame loss measurement (ETH-LM) between maintenance association end points (MEPs) configured on Ethernet physical or logical interfaces on MX Series routers and is presently supported only for VPWS service. ETH-LM is used by operators to collect counter values applicable for ingress and egress service frames. These counters maintain a count of transmitted and received data frames between a pair of MEPs. Ethernet frame loss measurement is performed by sending frames with ETH-LM information to a peer MEP and similarly receiving frames with ETH-LM information from the peer MEP. This type of frame loss measurement is also known as single-ended Ethernet loss measurement.
MX Series Virtual Chassis does not support Ethernet frame loss measurement (ETH-LM).
ETH-LM supports the following frame loss measurements:
Near-end frame loss measurement—Measurement of frame loss associated with ingress data frames.
Far-end frame loss measurement—Measurement of frame loss associated with egress data frames.
The proactive and dual-ended loss measurement functionality of ITU-T Y1731 is not supported on the ACX Series routers.
The ETH-LM feature is supported on aggregated Ethernet interfaces.
Starting Junos OS Release 16.1, the Ethernet loss measurement (ETH-LM) results are inaccurate when connectivity fault management (CFM) and performance monitoring (PM) PDUs received locally at a maintenance endpoint (MEP) as classified as belonging to the yellow class or a packet loss priority (PLP) of medium-high. This problem of incorrect results is specific to Ethernet loss measurement for CFM sessions of down MEPs. The Ethernet loss measurement statistics are inaccurate in the following scenarios:
Ethernet loss measurement is working on a CFM session for a MEP in down state
CFM PDUs received on the logical interface of the down MEP are classified by the classifier as yellow or medium-high PLP
A packet is identified as yellow when the input classifier marks the PLP as medium-high.
The problem of discrepancies with Ethernet loss measurement results is not observed when you configure Ethernet loss measurement in colorless mode. To avoid this problem of inaccurate loss measurement results, provision all local CFM PDUs as green or with the PLP as high.
Starting with Junos OS Release 16.1, performance monitoring
for connectivity fault management (by including the performance-monitoring statement and its substatements at the [edit protocols oam
ethernet connectivity-fault-management] hierarchy level) is
not supported when the network-to-network (NNI) or egress interface
is an aggregated Ethernet interface with member links on DPCs.
Service-Level Agreement Measurement
Service-level agreement (SLA) measurement is the process of monitoring the bandwidth, delay, delay variation (jitter), continuity, and availability of a service (E-Line or E-LAN). It enables you to identify network problems before customers are impacted by network defects.
The Ethernet VPN services can be classified into:
Peer-to-peer-services (E-Line services)—The E-Line services are offered using MPLS-based Layer 2 VPN virtual private wire service (VPWS).
Multipoint-to-multipoint services (E-LAN services)—The E-LAN services are offered using MPLS-based virtual private LAN service (VPLS).
For more information, see the Junos VPNs Configuration Guide.
In Junos OS, SLA measurements are classified into:
On-demand mode—In on-demand mode, the measurements are triggered through the CLI.
Proactive mode—In proactive mode, the measurements are triggered by an iterator application.
Note that Ethernet frame delay measurement and Ethernet frame
loss measurement are not supported on the ae interface.
On-Demand Mode for SLA Measurement
In on-demand mode, the measurements are triggered by the user through the CLI.
When the user triggers the delay measurement through the CLI,
the delay measurement request that is generated is as per the frame
formats specified by the ITU-T Y.1731 standard. For two-way delay
measurement, the server-side processing can be delegated to the Packet
Forwarding Engine to prevent overloading on the Routing Engine. For
more information, see Configuring Routers to Support an ETH-DM Session. When the server-side processing is delegated to the Packet Forwarding
Engine, the delay measurement message (DMM) frame receive counters and delay measurement reply (DMR) frame transmit counters are not displayed by the show command.
When the user triggers the loss measurement through the CLI,
the router sends the packets in standard format along with the loss
measurement TLV. By default, the session-id-tlv argument
is included in the packet to allow concurrent loss measurement sessions
from same local MEP. You can also disable the session ID TLV by using
the no-session-id-tlv argument.
Single-ended ETH-LM is used for on-demand operation, administration, and maintenance purposes. An MEP sends frames with ETH-LM request information to its peer MEP and receives frames with ETH-LM reply information from its peer MEP to carry out loss measurements. The protocol data unit (PDU) used for a single-ended ETH-LM request is referred to as a loss measurement message (LMM) and the PDU used for a single-ended ETH-LM reply is referred to as a loss measurement reply (LMR).
Proactive Mode for SLA Measurement
In proactive mode, SLA measurements are triggered by an iterator application. An iterator is designed to periodically transmit SLA measurement packets in form of ITU-Y.1731-compliant frames for two-way delay measurement or loss measurement on MX Series routers. This mode differs from on-demand SLA measurement, which is user initiated. The iterator sends periodic delay or loss measurement request packets for each of the connections registered to it. Iterators make sure that measurement cycles do not occur at the same time for the same connection to avoid CPU overload. Junos OS supports proactive mode for VPWS. For an iterator to form a remote adjacency and to become functionally operational, the continuity check message (CCM) must be active between the local and remote MEP configurations of the connectivity fault management (CFM). Any change in the iterator adjacency parameters resets the existing iterator statistics and restarts the iterator. Here, the term adjacency refers to a pairing of two endpoints (either connected directly or virtually) with relevant information for mutual understanding, which is used for subsequent processing. For example, the iterator adjacency refers to the iterator association between the two endpoints of the MEPs.
For every DPC or MPC, only 30 iterator instances for a cycle time value of 10 milliseconds (ms) are supported. In Junos OS, 255 iterator profile configurations and 2000 remote MEP associations are supported.
Iterators with cycle time value less than 100 ms are supported only for infinite iterators, whereas the iterators with cycle time value greater than 100 ms are supported for both finite and infinite iterators. Infinite iterators are iterators that run infinitely until the iterator is disabled or deactivated manually.
ACX5048 and ACX5096 routers supports iterator cycle time of only 1 second and above.
A VPWS service configured on a router is monitored for SLA measurements by registering the connection (here, the connection is a pair of remote and local MEPs) on an iterator and then initiating periodic SLA measurement frame transmission on those connections. The end-to-end service is identified through a maintenance association end point (MEP) configured at both ends.
For two-way delay measurement and loss measurement, an iterator sends a request message for the connection in the list (if any) and then sends a request message for the connection that was polled in the former iteration cycle. The back-to-back request messages for the SLA measurement frames and their responses help in computing delay variation and loss measurement.
The Y.1731 frame transmission for a service attached to an iterator continues endlessly unless intervened and stopped by an operator or until the iteration-count condition is met. To stop the iterator from sending out any more proactive SLA measurement frames, the operator must perform one of the following tasks:
Enable the
deactivate sla-iterator-profilestatement at the[edit protocols oam ethernet connectivity-fault-management maintenance-domain md-name maintenance association ma-name mep mep-id remote-mep mep-id]hierarchy level.Provision a
disablestatement under the corresponding iterator profile at the[edit protocols oam ethernet connectivity-fault-management performance-monitoring sla-iterator-profiles profile-name]hierarchy level.
Ethernet Delay Measurements and Loss Measurement by Proactive Mode
In two-way delay measurement, the delay measurement message (DMM) frame is triggered through an iterator application. The DMM frame carries an iterator type, length, and value (TLV) in addition to the fields described in standard frame format and the server copies the iterator TLV from the DMM frame to the delay measurement reply (DMR) frame.
In one-way delay variation computation using the two-way delay measurement method, the delay variation computation is based on the timestamps that are present in the DMR frame (and not the 1DM frame). Therefore, there is no need for client-side and server-side clocks to be in sync. Assuming that the difference in their clocks remains constant, the one-way delay variation results are expected to be fairly accurate. This method also eliminates the need to send separate 1DM frames just for the one-way delay variation measurement purpose.
In proactive mode for loss measurement, the router sends packets in standard format along with loss measurement TLV and iterator TLV.
Ethernet Failure Notification Protocol Overview
The Failure Notification Protocol (FNP) is a failure notification mechanism that detects failures in Point-to-Point Ethernet transport networks on MX Series routers. If a node link fails, FNP detects the failure and sends out FNP messages to the adjacent nodes that a circuit is down. Upon receiving the FNP message, nodes can redirect traffic to the protection circuit.
FNP is supported on E-Line services only.
An E-Line service provides a secure Point-to-Point Ethernet connectivity between two user network interfaces (UNIs). E-Line services are a protected service and each service has a working circuit and protection circuit. CFM is used to monitor the working and protect paths. CCM intervals result in failover time in hundreds of milliseconds or a few seconds. FNP provides service circuit failure detection and propagation in less than 50ms and provide 50ms failover for E-Line services.
The MX router acts as a PE node and handles the FNP messages received on the management VLAN and the FNP messages received on both the Ethernet interfaces and PWs created for the management VPLS. MX-series routers do not initiate FNP messages and responds only to FNP messages generated by devices in the Ethernet Access network. FNP can be enabled only on logical interfaces that are part of a VPLS routing instance, and no physical interfaces in that VPLS routing instance should have CCM configured. FNP can be enabled only on one logical interface per physical interface.
All E-Line services are configured as layer 2 circuits with edge protection. A VLAN associated with the working circuit or protection circuit must map to a logical interface. No trunk port or access port is supported in the ring link for VLANs used by E-LINE services. FNP does not control the logical interface associated with protection circuit. Only E-Line service whose termination point is not in an MX node is controlled by FNP.
FNP supports graceful restart and the Graceful Routing Engine switchover (GRES) features.
See Also
Ethernet Synthetic Loss Measurement Overview
Ethernet synthetic loss measurement (ETH-SLM) is an application that enables the calculation of frame loss by using synthetic frames instead of data traffic. This mechanism can be considered as a statistical sample to approximate the frame loss ratio of data traffic. Each maintenance association end point (MEP) performs frame loss measurements, which contribute to unavailable time.
A near-end frame loss specifies frame loss associated with ingress data frames and a far-end frame loss specifies frame loss associated with egress data frames. Both near-end and far-end frame loss measurements contribute to near-end severely errored seconds and far-end severely errored seconds that are used in combination to determine unavailable time. ETH-SLM is performed using synthetic loss message (SLM) and synthetic loss reply (SLR) frames. ETH-SLM facilitates each MEP to perform near-end and far-end synthetic frame loss measurements by using synthetic frames because a bidirectional service is defined as unavailable if either of the two directions is determined to be unavailable.
There are the two types of frame loss measurement, defined by the ITU-T Y.1731 standards, ETH-LM and ETH-SLM. Junos OS supports only single-ended ETH-SLM. In single-ended ETH-SLM, each MEP sends frames with the ETH-SLM request information to its peer MEP and receives frames with ETH-SLM reply information from its peer MEP to perform synthetic loss measurements. Single-ended ETH-SLM is used for proactive or on-demand OAM to perform synthetic loss measurements applicable to point-to-point Ethernet connection. This method allows a MEP to initiate and report far-end and near-end loss measurements associated with a pair of MEPs that are part of the same maintenance entity group (MEG).
MX Series Virtual Chassis does not support Ethernet synthetic loss measurement (ETH-SLM).
Single-ended ETH-SLM is used to perform on-demand or proactive tests by initiating a finite amount of ETH-SLM frames to one or multiple MEP peers and receiving the ETH-SLM reply from the peers. The ETH-SLM frames contain the ETH-SLM information that is used to measure and report both near-end and far-end synthetic loss measurements. Service-level agreement (SLA) measurement is the process of monitoring the bandwidth, delay, delay variation (jitter), continuity, and availability of a service. It enables you to identify network problems before customers are impacted by network defects. In proactive mode, SLA measurements are triggered by an iterator application. An iterator is designed to periodically transmit SLA measurement packets in the form of ITU-Y.1731-compliant frames for synthetic frame loss measurement . This mode differs from on-demand SLA measurement, which is user initiated. In on-demand mode, the measurements are triggered by the user through the CLI. When the user triggers the ETH-SLM through the CLI, the SLM request that is generated is as per the frame formats specified by the ITU-T Y.1731 standard.
ACX5048 and ACX5096 routers support ETH-SLM for Layer 2 services.
Scenarios for Configuration of ETH-SLM
ETH-SLM measures near-end and far-end frame loss between two MEPs that are part of the same MEG level. You can configure ETH-SLM to measure synthetic loss for both upward-facing or upstream MEP and downward-facing or downstream MEP. This section describes the following scenarios for the operation of ETH-SLM:
Upstream MEP in MPLS Tunnels
Consider a scenario in which a MEP is configured between the user network interfaces (UNIs) of two MX Series routers, MX1 and MX2, in the upstream direction. MX1 and MX2 are connected over an MPLS core network. ETH-SLM measurements are performed between the upstream MEP in the path linking the two routers. Both MX1 and MX2 can initiate on-demand or proactive ETH-SLM, which can measure both far-end and near-end loss at MX1 and MX2, respectively. The two UNIs are connected using MPLS-based Layer 2 VPN virtual private wire service (VPWS).
Downstream MEP in Ethernet Networks
Consider a scenario in which a MEP is configured between two MX Series routers, MX1 and MX2, on the Ethernet interfaces in the downstream direction. MX1 and MX2 are connected in an Ethernet topology and downstream MEP is configured toward the Ethernet network. ETH-SLM measurements are performed between the downstream MEP in the path linking the two routers. ETH-SLM can be measured in the path between these two routers.
Consider another scenario in which a MEP is configured in the downstream direction and service protection for a VPWS over MPLS is enabled by specifying a working path or protect path on the MEP. Service protection provides end-to-end connection protection of the working path in the event of a failure. To configure service protection, you must create two separate transport paths—a working path and a protect path. You can specify the working path and protect path by creating two maintenance associations. To associate the maintenance association with a path, you must configure the MEP interface in the maintenance association and specify the path as working or protect.
In a sample topology, an MX Series router, MX1, is connected to two other MX Series routers, MX2 and MX3, over an MPLS core. The connectivity fault management (CFM) session between MX1 and MX2 is the working path on the MEP and the CFM session between MX1 and MX3 is the protect path on the MEP. MX2 and MX3 are, in turn, connected on Ethernet interfaces to MX4 in the access network. Downstream MEP is configured between MX1 and MX4 that passes through MX2 (working CFM session) and also between MX1 and MX4 that passes through MX3 (protected CFM session). ETH-SLM is performed between these downstream MEPs. In both the downstream MEPs, the configuration is performed on MX1 and MX4 UNIs, similar to upstream MEP.
Format of ETH-SLM Messages
Synthetic loss messages (SLMs) support single-ended Ethernet synthetic loss measurement (ETH-SLM) requests. This topic contains the following sections that describe the formats of the SLM protocol data units (PDUs), SLR PDUs, and the data iterator type length value (TLV).
SLM PDU Format
The SLM PDU format is used by a MEP to transmit SLM information. The following components are contained in SLM PDUs:
Source MEP ID—Source MEP ID is a 2-octet field where the last 13 least significant bits are used to identify the MEP transmitting the SLM frame. MEP ID is unique within the MEG.
Test ID—Test ID is a 4-octet field set by the transmitting MEP and is used to identify a test when multiple tests run simultaneously between MEPs (including both concurrent on-demand and proactive tests).
TxFCf—TxFCf is a 4-octet field that carries the number of SLM frames transmitted by the MEP toward its peer MEP.
The following are the fields in an SLM PDU:
MEG Level—Configured maintenance domain level in the range 0–7.
Version—0.
OpCode—Identifies an OAM PDU type. For SLM, it is 55.
Flags—Set to all zeros.
TLV Offset—16.
Source MEP ID—A 2-octet field used to identify the MEP transmitting the SLM frame. In this 2-octet field, the last 13 least significant bits are used to identify the MEP transmitting the SLM frame. MEP ID is unique within the MEG.
RESV—Reserved fields are set to all zeros.
Test ID—A 4-octet field set by the transmitting MEP and used to identify a test when multiple tests run simultaneously between MEPs (including both concurrent on-demand and proactive tests).
TxFCf—A 4-octet field that carries the number of SLM frames transmitted by the MEP toward its peer MEP.
Optional TLV—A data TLV may be included in any SLM transmitted. For the purpose of ETH-SLM, the value part of data TLV is unspecified.
End TLV—All zeros octet value.
SLR PDU Format
The synthetic loss reply (SLR) PDU format is used by a MEP to transmit SLR information. The following are the fields in an SLR PDU:
MEG Level—A 3-bit field the value of which is copied from the last received SLM PDU.
Version—A 5-bit field the value of which is copied from the last received SLM PDU.
OpCode—Identifies an OAM PDU type. For SLR, it is set as 54.
Flags—A 1-octet field copied from the SLM PDU.
TLV Offset—A 1-octet field copied from the SLM PDU.
Source MEP ID—A 2-octet field copied from the SLM PDU.
Responder MEP ID—A 2-octet field used to identify the MEP transmitting the SLR frame.
Test ID—A 4-octet field copied from the SLM PDU.
TxFCf—A 4-octet field copied from the SLM PDU.
TxFCb—A 4 octet field. This value represents the number of SLR frames transmitted for this test ID.
Optional TLV—The value is copied from the SLM PDU, if present.
End TLV—A 1-octet field copied from the SLM PDU.
Data Iterator TLV Format
The data iterator TLV specifies the data TLV portion of the Y.1731 data frame. The MEP uses a data TLV when the MEP is configured to measure delay and delay variation for different frame sizes. The following are the fields in a data TLV:
Type—Identifies the TLV type; value for this TLV type is Data (3).
Length—Identifies the size, in octets, of the Value field containing the data pattern. The maximum value of the Length field is 1440.
Data pattern—An n-octet (n denotes length) arbitrary bit pattern. The receiver ignores it.
Transmission of ETH-SLM Messages
The ETH-SLM functionality can process multiple synthetic loss message (SLM) requests simultaneously between a pair of MEPs. The session can be a proactive or an on-demand SLM session. Each SLM request is identified uniquely by a test ID.
A MEP can send SLM requests or respond to SLM requests. A response to an SLM request is called a synthetic loss reply (SLR). After a MEP determines an SLM request by using the test ID, the MEP calculates the far-end and near-end frame loss on the basis of the information in the SLM message or the SLM protocol data unit (PDU).
A MEP maintains the following local counters for each test ID and for each peer MEP being monitored in a maintenance entity for which loss measurements are to be performed:
TxFCl—Number of synthetic frames transmitted toward the peer MEP for a test ID. A source MEP increments this number for successive transmission of synthetic frames with ETH-SLM request information while a destination or receiving MEP increments this value for successive transmission of synthetic frames with the SLR information.
RxFCl—Number of synthetic frames received from the peer MEP for a test ID. A source MEP increments this number for successive reception of synthetic frames with SLR information while a destination or receiving MEP increments it for successive reception of synthetic frames with ETH-SLM request information.
The following sections describe the phases of processing of SLM PDUs to determine synthetic frame loss:
- Initiation and Transmission of SLM Requests
- Reception of SLMs and Transmission of SLRs
- Reception of SLRs
- Computation of Frame Loss
Initiation and Transmission of SLM Requests
A MEP periodically transmits an SLM request with the OpCode field set as 55. The MEP generates a unique Test ID for the session, adds the source MEP ID, and initializes the local counters for the session before SLM initiation. For each SLM PDU transmitted for the session (test ID), the local counter TxFCl is sent in the packet.
No synchronization is required of the test ID value between initiating and responding MEPs because the test ID is configured at the initiating MEP, and the responding MEP uses the test ID it receives from the initiating MEP. Because ETH-SLM is a sampling technique, it is less precise than counting the service frames. Also, the accuracy of measurement depends on the number of SLM frames used or the period for transmitting SLM frames.
Reception of SLMs and Transmission of SLRs
After the destination MEP receives a valid SLM frame from the source MEP, an SLR frame is generated and transmitted to the requesting or source MEP. The SLR frame is valid if the MEG level and the destination MAC address match the receiving MEP’s MAC address. All the fields in the SLM PDUs are copied from the SLM request except for the following fields:
The source MAC address is copied to the destination MAC address and the source address contains the MEP’s MAC address.
The value of the OpCode field is changed from SLM to SLR (54).
The responder MEP ID is populated with the MEP’s MEP ID.
TxFCb is saved with the value of the local counter RxFCl at the time of SLR frame transmission.
An SLR frame is generated every time an SLM frame is received; therefore, RxFCl in the responder is equal to the number of SLM frames received and also equal to the number of SLR frames sent. At the responder or receiving MEP, RxFCl equals TxFCl.
Reception of SLRs
After an SLM frame (with a given TxFCf value) is transmitted, a MEP expects to receive a corresponding SLR frame (carrying the same TxTCf value) within the timeout value from its peer MEP. SLR frames that are received after the timeout value (5 seconds) are discarded. With the information contained in SLR frames, a MEP determines the frame loss for the specified measurement period. The measurement period is a time interval during which the number of SLM frames transmitted is statistically adequate to make a measurement at a given accuracy. A MEP uses the following values to determine near-end and far-end frame loss during the measurement period:
Last received SLR frame's TxFCf and TxFCb values and the local counter RxFCl value at the end of the measurement period. These values are represented as TxFCf[tc], TxFCb[tc], and RxFCl[tc], where tc is the end time of the measurement period.
SLR frame's TxFCf and TxFCb values of the first received SLR frame after the test starts and local counter RxFCl at the beginning of the measurement period. These values are represented as TxFCf[tp], TxFCb[tp], and RxFCl[tp], where tp is the start time of the measurement period.
For each SLR packet that is received, the local RxFCl counter is incremented at the sending or source MEP.
Computation of Frame Loss
Synthetic frame loss is calculated at the end of the measurement period on the basis of the value of the local counters and the information from the last frame received. The last received frames contains the TxFCf and TxFCb values. The local counter contains the RxFCl value. Using these values, frame loss is determined using the following formula:
Frame loss (far-end) = TxFCf – TxFCb
Frame loss (near-end) = TxFCb – RxFCl
Change History Table
Feature support is determined by the platform and release you are using. Use Feature Explorer to determine if a feature is supported on your platform.
performance-monitoring statement and its substatements at the [edit protocols oam
ethernet connectivity-fault-management] hierarchy level) is
not supported when the network-to-network (NNI) or egress interface
is an aggregated Ethernet interface with member links on DPCs.