SUMMARYThis 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 mechanismsto detect and report link faults on a single point-to-point EthernetLAN.
Junos OS supports key OAM standards that provide for automatedend-to-end management and monitoring of Ethernet service by serviceproviders:
IEEE Standard 802.1ag, also knownas “Connectivity Fault Management (CFM).”
ITU-T Recommendation Y.1731, whichuses different terminology than IEEE 802.1ag and defines Ethernetservice OAM features for fault monitoring, diagnostics, and performancemonitoring.
These capabilities allow operators to offer binding service-levelagreements (SLAs) and generate new revenues from rate- and performance-guaranteedservice packages that are tailored to the specific needs of theircustomers.
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.
Note:
ACX5048 and ACX5096 routers supports only software-based timestamping for delay measurement.
- Ethernet CFM
- Ethernet Frame Delay Measurement
Ethernet CFM
The IEEE 802.1ag standard for connectivity fault management(CFM) defines mechanisms to provide for end-to-end Ethernet serviceassurance over any path, whether a single link or multiple links spanningnetworks 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 ContinuityCheck protocol
Path discovery and fault verification using the IEEE 802.1agEthernet OAM Linktrace protocol
Fault isolation using the IEEE 802.1ag Ethernet OAM Loopbackprotocol
In a CFM environment, network entities such as network operators,service providers, and customers may be part of different administrativedomains. Each administrative domain is mapped into one maintenancedomain. Maintenance domains are configured with different level valuesto keep them separate. Each domain provides enough information forthe 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 operatorEthernet bridges, maintenance domains, maintenance association endpoints (MEPs), and maintenance intermediate points (MIPs).
Figure 1: Relationshipof MEPs, MIPs, and Maintenance Domain Levels
Note:
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-serviceattributes such as frame delay and frame delay variation (also knownas “frame jitter”). Suchmeasurements can enable you to identify network problems before customersare impacted by network defects.
Junos OS supports Ethernet frame delay measurement between MEPsconfigured on Ethernet physical or logical interfaces on MX Seriesrouters. Ethernet frame delay measurement provides fine control tooperators for triggering delay measurement on a given service andcan be used to monitor SLAs. Ethernet frame delay measurement alsocollects other useful information, such as worst and best case delays,average delay, and average delay variation. The Junos OS implementationof Ethernet frame delay measurement (ETH-DM) is fully compliant withthe ITU-T Recommendation Y.1731, OAM Functions and Mechanismsfor Ethernet-based Networks. The recommendation definesOAM mechanisms for operating and maintaining the network at the Ethernetservice layer, which is called the "ETH layer" in ITU-T terminology.
MX Series routers with modular port concentrators (MPCs) and10-Gigabit Ethernet MPCs with SFP+ support ITU-T Y.1731 functionalityon VPLS for frame-delay and delay-variation.
Note:
MX Series Virtual Chassis does not support Ethernet frame delaymeasurement (DM).
One-Way Ethernet Frame Delay Measurement
In one-way ETH-DM mode, a series of frame delay and frame delayvariation values are calculated based on the time elapsed betweenthe time a measurement frame is sent from the initiator MEP at onerouter and the time when the frame is received at the receiver MEPat the other router.
Note:
ACX Series routers do not support one-way Ethernet frame delaymeasurement.
- 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 routersends 1DM frames—frames that carry the protocol data unit (PDU)for a one-way delay measurement—from the initiator MEP to thereceiver MEP at the rate and for the number of frames you specify.The router marks each 1DM frame as drop-ineligible and inserts a timestampof the transmission time into the frame.
1DM Reception
When an MEP receives a 1DM frame, the router that contains thereceiver MEP measures the one-way delay for that frame (the differencebetween the time the frame was received and the timestamp containedin the frame itself) and the delay variation (the difference betweenthe current and previous delay values).
One-Way ETH-DM Statistics
The router that contains the receiver MEP stores each set ofone-way delay statistics in the ETH-DM database. The ETH-DM databasecollects up to 100 sets of statistics for any given CFM session (pairof peer MEPs). You can access these statistics at any time by displayingthe ETH-DM database contents.
One-Way ETH-DM Frame Counts
Each router counts the number of one-way ETH-DM frames sentand received:
For an initiator MEP, the router counts the number of1DM frames sent.
For a receiver MEP, the router counts the number of valid1DM 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 interfacesthat support ETH-DM, any ETH-DM frame counts. You can access the framecounts at any time by displaying CFM database information for Ethernetinterfaces assigned to MEPs or for MEPs in CFM sessions.
Synchronization of System Clocks
The accuracy of one-way delay calculations depends on closesynchronization of the system clocks at the initiator MEP and receiverMEP.
The accuracy of one-way delay variation is not dependent onsystem clock synchronization. Because delay variation is simply thedifference between consecutive one-way delay values, the out-of-phaseperiod is eliminated from the frame jitter values.
Note:
For a given one-way Ethernet frame delay measurement, framedelay and frame delay variation values are available only on the routerthat contains the receiver MEP.
Two-Way Ethernet Frame Delay Measurement
In two-way ETH-DM mode, frame delay and frame delay variationvalues are based on the time difference between when the initiatorMEP transmits a request frame and receives a reply frame from theresponder 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 routersends delay measurement message (DMM) frames— frames that carrythe PDU for a two-way ETH-DM request—from the initiator MEPto the responder MEP at the rate and for the number of frames youspecify. The router marks each DMM frame as drop-ineligible and insertsa timestamp of the transmission time into the frame.
DMR Transmission
When an MEP receives a DMM frame, the responder MEP respondswith a delay measurement reply (DMR) frame, which carries ETH-DM replyinformation and a copy of the timestamp contained in the DMM frame.
DMR Reception
When an MEP receives a valid DMR, the router that contains theMEP measures the two-way delay for that frame based on the followingsequence 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 betweenthe time at which the initiator MEP sends a DMM frame and the timeat which the initiator MEP receives the associated DMR frame fromthe responder MEP, minus the time elapsed at the responder MEP.
The delay variation is the difference between the current andprevious delay values.
Two-Way ETH-DM Statistics
The router that contains the initiator MEP stores each set oftwo-way delay statistics in the ETH-DM database. The ETH-DM databasecollects up to 100 sets of statistics for any given CFM session (pairof peer MEPs). You can access these statistics at any time by displayingthe ETH-DM database contents.
Two-Way ETH-DM Frame Counts
Each router counts the number of two-way ETH-DM frames sentand received:
For an initiator MEP, the router counts the number DMMframes transmitted, the number of valid DMR frames received, and thenumber of invalid DMR frames received.
For a responder MEP, the router counts the number of DMRframes sent.
Each router stores ETH-DM frame counts in the CFM database.The CFM database stores CFM session statistics and, for interfacesthat support ETH-DM, any ETH-DM frame counts. You can access the framecounts at any time by displaying CFM database information for Ethernetinterfaces assigned to MEPs or for MEPs in CFM sessions.
Note:
For a given two-way Ethernet frame delay measurement, framedelay and frame delay variation values are available only at the routerthat contains the initiator MEP.
Choosing Between One-Way and Two-Way ETH-DM
One-way frame delay measurement requires that the system clocksat the initiator MEP and receiver MEP are closely synchronized. Two-wayframe delay measurement does not require synchronization of the twosystems. 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-waydelay values are very high compared to their two-way delay values.One-way delay measurement requires that the timing for the two systemsbe synchronized at a very granular level, and MX Series routers currentlydo not support this granular synchronization.
Restrictions for Ethernet Frame Delay Measurement
The following restrictions apply to the Ethernet frame delaymeasurement feature:
The ETH-DM feature is not supported on label-switchedinterface (LSI) pseudowires.
The ETH-DM feature is supported on aggregated Ethernet interfaces.
Hardware-assisted timestamping for ETH-DM frames in thereception path is only supported for MEP interfaces on Enhanced DPCsand Enhanced Queuing DPCs in MX Series routers. For information abouthardware-assisted timestamping, see Guidelines for Configuring Routers to Support anETH-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 anETH-DM Session and Ensuring That Distributed ppm Is Not Disabled.You can monitor only one session at a time to the sameremote MEP or MAC address. For more information about starting anETH-DM session, see Starting an ETH-DM Session.
ETH-DM statistics are collected at only one of the twopeer 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-DMsession, you can display frame delay statistics at the initiator MEPonly, using the same ETH-DM-specificshowcommands. Formore information, see Managing ETH-DM Statistics and ETH-DM Frame Counts.ETH-DM frame counts are collected at both MEPs and arestored in the respective CFM databases.
If graceful Routing Engine switchover (GRES) occurs, any collected ETH-DM statistics are lost, and ETH-DMframe counts are reset to zeroes. Therefore, the collection of ETH-DMstatistics and ETH-DM frame counters has to be restarted, after theswitchover is complete. GRES enables a router with dual Routing Enginesto switch from a primary Routing Engine to a backup Routing Enginewithout interruption to packet forwarding. For more information, seethe Junos OS High Availability User Guide.
Accuracy of frame delay statistics is compromised whenthe system is changing (such as from reconfiguration). We recommendperforming Ethernet frame delay measurements on a stable system.
Ethernet Frame Loss Measurement Overview
The key objectives of the OAM functionality are to measurequality-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 problemsbefore customers are impacted by network defects.
Junos OS supports Ethernet frame loss measurement (ETH-LM) betweenmaintenance association end points (MEPs) configured on Ethernet physicalor logical interfaces on MX Series routers and is presently supportedonly for VPWS service. ETH-LM is usedby operators to collect counter values applicable for ingress andegress service frames. These counters maintain a count of transmittedand received data frames between a pair of MEPs. Ethernet frame lossmeasurement is performed by sending frames with ETH-LM informationto a peer MEP and similarly receiving frames with ETH-LM informationfrom the peer MEP. This type of frame loss measurement is also knownas single-ended Ethernet loss measurement.
Note:
MX Series Virtual Chassis does not support Ethernet frameloss measurement (ETH-LM).
ETH-LM supports the following frame loss measurements:
Near-end frame loss measurement—Measurement of frameloss associated with ingress data frames.
Far-end frame loss measurement—Measurement of frameloss associated with egress data frames.
Note:
The proactive and dual-ended loss measurement functionalityof ITU-T Y1731 is not supported on the ACX Series routers.
The ETH-LM feature is supported on aggregated Ethernet interfaces.
Note:
Starting Junos OS Release16.1, the Ethernet loss measurement (ETH-LM) results are inaccuratewhen connectivity fault management (CFM) and performance monitoring(PM) PDUs received locally at a maintenance endpoint (MEP) as classifiedas belonging to the yellow class or a packet loss priority (PLP) ofmedium-high. This problem of incorrect resultsis specific to Ethernet loss measurement for CFM sessions of downMEPs. The Ethernet loss measurement statistics are inaccurate in thefollowing scenarios:
Ethernet loss measurement is working on a CFM sessionfor a MEP in down state
CFM PDUs received on the logical interface of the downMEP are classified by the classifier as yellow or medium-high PLP
A packet is identified as yellow when the input classifiermarks the PLP as medium-high.
The problem of discrepancies with Ethernet loss measurementresults is not observed when you configure Ethernet loss measurementin colorless mode. To avoid this problem of inaccurate loss measurementresults, provision all local CFM PDUs as green or with the PLP ashigh.
Note:
Starting with Junos OS Release 16.1, performance monitoringfor connectivity fault management (by including the performance-monitoring statement and its substatements at the [edit protocols oamethernet connectivity-fault-management] hierarchy level) isnot supported when the network-to-network (NNI) or egress interfaceis an aggregated Ethernet interface with member links on DPCs.
Service-Level Agreement Measurement
Service-level agreement (SLA) measurement is the processof 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 beforecustomers are impacted by network defects.
Note:
The Ethernet VPN services can be classified into:
Peer-to-peer-services (E-Line services)—The E-Lineservices are offered using MPLS-based Layer 2 VPN virtualprivate wire service (VPWS).
Multipoint-to-multipoint services (E-LAN services)—TheE-LAN services are offered using MPLS-based virtual private LAN service(VPLS).
For more information, see the Junos VPNs ConfigurationGuide.
In Junos OS, SLA measurements are classified into:
On-demand mode—In on-demand mode, the measurementsare triggered through the CLI.
Proactive mode—In proactive mode, the measurementsare triggered by an iterator application.
Note that Ethernet frame delay measurement and Ethernet frameloss measurement are not supported on the ae interface.
On-Demand Mode for SLA Measurement
In on-demand mode, the measurements are triggered bythe 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 frameformats specified by the ITU-T Y.1731 standard. For two-way delaymeasurement, the server-side processing can be delegated to the PacketForwarding Engine to prevent overloading on the Routing Engine. Formore information, see Configuring Routers to Support an ETH-DM Session. When the server-side processing is delegated to the Packet ForwardingEngine, 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 lossmeasurement TLV. By default, the session-id-tlv argumentis included in the packet to allow concurrent loss measurement sessionsfrom same local MEP. You can also disable the session ID TLV by usingthe 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 requestinformation to its peer MEP and receives frames with ETH-LM replyinformation from its peer MEP to carry out loss measurements. Theprotocol data unit (PDU) used for a single-ended ETH-LM request isreferred to as a loss measurement message (LMM) and the PDU used fora 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 byan iterator application. An iterator is designed to periodically transmitSLA measurement packets in form of ITU-Y.1731-compliant frames fortwo-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 packetsfor each of the connections registered to it. Iterators make surethat measurement cycles do not occur at the same time for the sameconnection to avoid CPU overload. Junos OS supports proactive modefor VPWS. For an iterator to form aremote adjacency and to become functionally operational, the continuitycheck message (CCM) must be active between the local and remote MEPconfigurations of the connectivity fault management (CFM). Any changein the iterator adjacency parameters resets the existing iteratorstatistics and restarts the iterator. Here, the term adjacency refersto a pairing of two endpoints (either connected directly or virtually)with relevant information for mutual understanding, which is usedfor subsequent processing. For example, the iterator adjacency refersto the iterator association between the two endpoints of the MEPs.
For every DPC or MPC, only 30 iterator instances for a cycletime value of 10milliseconds (ms) are supported. In Junos OS,255 iterator profile configurations and 2000 remote MEP associationsare supported.
Iterators with cycle time value less than 100ms are supportedonly for infinite iterators, whereas the iterators with cycle timevalue greater than 100ms are supported for both finite and infiniteiterators. Infinite iterators are iterators that run infinitely untilthe iterator is disabled or deactivated manually.
Note:
ACX5048 and ACX5096 routers supports iterator cycle timeof only 1 second and above.
A VPWS service configured on a router is monitored for SLA measurementsby registering the connection (here, the connection is a pair of remoteand local MEPs) on an iterator and then initiating periodic SLA measurementframe transmission on those connections. The end-to-end service isidentified through a maintenance association end point (MEP) configuredat both ends.
For two-way delay measurement and loss measurement, an iteratorsends a request message for the connection in the list (if any) andthen sends a request message for the connection that was polled inthe former iteration cycle. The back-to-back request messages forthe SLA measurement frames and their responses help in computing delayvariation and loss measurement.
The Y.1731 frame transmission for a service attachedto an iterator continues endlessly unless intervened and stopped byan operator or until the iteration-count condition is met. To stopthe iterator from sending out any more proactive SLA measurement frames,the operator must perform one of the following tasks:
Enable the
deactivate sla-iterator-profilestatementat the[edit protocols oam ethernet connectivity-fault-managementmaintenance-domain md-name maintenance association ma-name mep mep-id remote-mep mep-id]hierarchy level.Provision a
disablestatement under the correspondingiterator profile at the[edit protocols oam ethernet connectivity-fault-managementperformance-monitoring sla-iterator-profiles profile-name]hierarchy level.
Ethernet Delay Measurements and Loss Measurement by ProactiveMode
In two-way delay measurement, the delay measurement message(DMM) frame is triggered through an iterator application. The DMMframe carries an iterator type, length, and value (TLV) in additionto the fields described in standard frame format and the server copiesthe iterator TLV from the DMM frame to the delay measurement reply(DMR) frame.
In one-way delay variation computation using the two-way delaymeasurement method, the delay variation computation is based on thetimestamps that are present in the DMR frame (and not the 1DM frame).Therefore, there is no need for client-side and server-side clocksto be in sync. Assuming that the difference in their clocks remainsconstant, the one-way delay variation results are expected to be fairlyaccurate. This method also eliminates the need to send separate 1DMframes just for the one-way delay variation measurement purpose.
In proactive mode for loss measurement, the router sends packetsin standard format along with loss measurement TLV and iterator TLV.
Ethernet Failure Notification Protocol Overview
The Failure Notification Protocol (FNP) is a failure notificationmechanism that detects failures in Point-to-Point Ethernet transportnetworks on MX Series routers. If a node link fails, FNP detects thefailure and sends out FNP messages to the adjacent nodes that a circuitis down. Upon receiving the FNP message, nodes can redirect trafficto the protection circuit.
Note:
FNP is supported on E-Line services only.
An E-Line service provides a secure Point-to-Point Ethernetconnectivity between two user network interfaces (UNIs). E-Line servicesare a protected service and each service has a working circuit andprotection circuit. CFM is used to monitor the working and protectpaths. CCM intervals result in failover time in hundreds of millisecondsor a few seconds. FNP provides service circuit failure detection andpropagation in less than 50ms and provide 50ms failover for E-Lineservices.
The MX router acts as a PE node and handles the FNP messagesreceived on the management VLAN and the FNP messages received on boththe Ethernet interfaces and PWs created for the management VPLS. MX-seriesrouters do not initiate FNP messages and responds only to FNP messagesgenerated by devices in the Ethernet Access network. FNP can be enabledonly on logical interfaces that are part of a VPLS routing instance,and no physical interfaces in that VPLS routing instance should haveCCM configured. FNP can be enabled only on one logicalinterface per physical interface.
All E-Line services are configured as layer 2 circuits withedge protection. A VLAN associated with the working circuit or protectioncircuit must map to a logical interface. No trunk port or access portis supported in the ring link for VLANs used by E-LINE services. FNPdoes not control the logical interface associated with protectioncircuit. Only E-Line service whose termination point is not in anMX node is controlled by FNP.
FNP supports graceful restart and the GracefulRouting Engine switchover (GRES) features.
See Also
show oam ethernet fnp interface
show oam ethernet fnp status
show oam ethernet fnp messages
connectivity-fault-management
Ethernet Synthetic Loss Measurement Overview
Ethernet synthetic loss measurement (ETH-SLM) is an applicationthat enables the calculation of frame loss by using synthetic framesinstead of data traffic. This mechanism can be considered as a statisticalsample to approximate the frame loss ratio of data traffic. Eachmaintenance association end point (MEP) performs frame loss measurements,which contribute to unavailable time.
A near-end frame loss specifies frame loss associated with ingressdata frames and a far-end frame loss specifies frame loss associatedwith egress data frames. Both near-end and far-end frame loss measurementscontribute to near-end severely errored seconds and far-end severelyerrored seconds that are used in combination to determine unavailabletime. ETH-SLM is performed using synthetic loss message (SLM) andsynthetic loss reply (SLR) frames. ETH-SLM facilitates each MEP toperform near-end and far-end synthetic frame loss measurements byusing synthetic frames because a bidirectional service is definedas unavailable if either of the two directions is determined to beunavailable.
There are the two types of frame loss measurement, defined bythe ITU-T Y.1731 standards, ETH-LM and ETH-SLM. Junos OS supportsonly single-ended ETH-SLM. In single-ended ETH-SLM, each MEP sendsframes with the ETH-SLM request information to its peer MEP and receivesframes with ETH-SLM reply information from its peer MEP to perform synthetic loss measurements. Single-ended ETH-SLM is used for proactiveor on-demand OAM to perform synthetic loss measurements applicableto point-to-point Ethernet connection. This method allows a MEP toinitiate and report far-end and near-end loss measurements associatedwith a pair of MEPs that are part of the same maintenance entity group (MEG).
Note:
MX Series Virtual Chassis does not support Ethernet syntheticloss measurement (ETH-SLM).
Single-ended ETH-SLM is used to perform on-demand or proactivetests by initiating a finite amount of ETH-SLM frames to one or multipleMEP peers and receiving the ETH-SLM reply from the peers. The ETH-SLMframes contain the ETH-SLM information that is used to measure andreport both near-end and far-end synthetic loss measurements. Service-levelagreement (SLA) measurement is the process of monitoring the bandwidth,delay, delay variation (jitter), continuity,and availability of a service. It enables you to identify networkproblems before customers are impacted by network defects. In proactivemode, SLA measurements are triggered by an iterator application. Aniterator is designed to periodically transmit SLA measurement packetsin the form of ITU-Y.1731-compliant frames for synthetic frame lossmeasurement . This mode differs from on-demand SLA measurement, whichis user initiated. In on-demand mode, the measurements are triggeredby the user through the CLI. When the user triggers the ETH-SLM throughthe CLI, the SLM request that is generated is as per the frame formatsspecified by the ITU-T Y.1731 standard.
Note:
ACX5048 and ACX5096 routers support ETH-SLM for Layer2 services.
Scenarios for Configuration of ETH-SLM
ETH-SLM measures near-end and far-end frame loss between twoMEPs that are part of the same MEG level. You can configure ETH-SLMto measure synthetic loss for both upward-facing or upstream MEP anddownward-facing or downstream MEP. This section describes the followingscenarios for the operation of ETH-SLM:
- Upstream MEP in MPLS Tunnels
- Downstream MEP in Ethernet Networks
Upstream MEP in MPLS Tunnels
Consider a scenario in which a MEP is configured between theuser network interfaces (UNIs) of two MX Series routers, MX1 and MX2,in the upstream direction. MX1 and MX2 are connected over an MPLScore network. ETH-SLM measurements are performed between the upstreamMEP in the path linking the two routers. Both MX1 and MX2 can initiateon-demand or proactive ETH-SLM, which can measure both far-end andnear-end loss at MX1 and MX2, respectively. The two UNIs are connectedusing 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 twoMX Series routers, MX1 and MX2, on the Ethernet interfaces in thedownstream direction. MX1 and MX2 are connected in an Ethernet topologyand downstream MEP is configured toward the Ethernet network. ETH-SLMmeasurements are performed between the downstream MEP in the path linking the two routers. ETH-SLM can be measured in the path betweenthese two routers.
Consider another scenario in which a MEP is configured in thedownstream direction and service protection for a VPWS over MPLSis enabled by specifying a working path or protect path on the MEP. Service protection provides end-to-end connection protection of theworking path in the event of a failure. To configure service protection,you must create two separate transport paths—a working pathand a protect path. You can specify the working path and protectpath by creating two maintenance associations. To associate the maintenance association with a path, you must configure the MEP interface inthe maintenance association and specify the path as working or protect.
In a sample topology, an MX Series router, MX1, is connectedto two other MX Series routers, MX2 and MX3, over an MPLS core. Theconnectivity fault management (CFM) session between MX1 and MX2 isthe working path on the MEP and the CFM session between MX1 and MX3is the protect path on the MEP. MX2 and MX3 are, in turn, connectedon Ethernet interfaces to MX4 in the access network. Downstream MEPis configured between MX1 and MX4 that passes through MX2 (workingCFM session) and also between MX1 and MX4 that passes through MX3(protected CFM session). ETH-SLM is performed between these downstreamMEPs. In both the downstream MEPs, the configuration is performedon MX1 and MX4 UNIs, similar to upstream MEP.
Format of ETH-SLM Messages
Synthetic loss messages (SLMs) support single-ended Ethernetsynthetic loss measurement (ETH-SLM) requests. This topic containsthe following sections that describe the formats of the SLM protocoldata units (PDUs), SLR PDUs, and the data iterator type length value(TLV).
- SLM PDU Format
- SLR PDU Format
- Data Iterator TLV Format
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 wherethe last 13 least significant bits are used to identify the MEP transmittingthe SLM frame. MEP ID is unique within the MEG.
Test ID—Test ID is a 4-octet field set by the transmittingMEP and is used to identify a test when multiple tests run simultaneouslybetween MEPs (including both concurrent on-demand and proactive tests).
TxFCf—TxFCf is a 4-octet field that carries thenumber 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 inthe range 0–7.
Version—0.
OpCode—Identifies an OAM PDU type. For SLM, it is55.
Flags—Set to all zeros.
TLV Offset—16.
Source MEP ID—A 2-octet field used to identify theMEP transmitting the SLM frame. In this 2-octet field, the last 13least significant bits are used to identify the MEP transmitting theSLM 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 transmittingMEP and used to identify a test when multiple tests run simultaneouslybetween MEPs (including both concurrent on-demand and proactive tests).
TxFCf—A 4-octet field that carries the number ofSLM frames transmitted by the MEP toward its peer MEP.
Optional TLV—A data TLV may be included in any SLMtransmitted. For the purpose of ETH-SLM, the value part of data TLVis unspecified.
End TLV—All zeros octet value.
SLR PDU Format
The synthetic loss reply (SLR) PDU format is used by a MEP totransmit SLR information. The following are the fields in an SLR PDU:
MEG Level—A 3-bit field the value of which is copiedfrom the last received SLM PDU.
Version—A 5-bit field the value of which is copiedfrom the last received SLM PDU.
OpCode—Identifies an OAM PDU type. For SLR, it isset 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 SLMPDU.
Responder MEP ID—A 2-octet field used to identifythe 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 thenumber 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 theY.1731 data frame. The MEP uses a data TLV when the MEP is configuredto measure delay and delay variation for different frame sizes. Thefollowing are the fields in a data TLV:
Type—Identifies the TLV type; value for this TLVtype is Data (3).
Length—Identifies the size, in octets, of the Valuefield containing the data pattern. The maximum value of the Lengthfield is 1440.
Data pattern—An n-octet (n denotes length) arbitrary bit pattern. The receiverignores it.
Transmission of ETH-SLM Messages
The ETH-SLM functionality can process multiple synthetic lossmessage (SLM) requests simultaneously between a pair of MEPs. Thesession can be a proactive or an on-demand SLM session. Each SLMrequest is identified uniquely by a test ID.
A MEP can send SLM requests or respond to SLM requests. A responseto an SLM request is called a synthetic loss reply (SLR). After aMEP determines an SLM request by using the test ID, the MEP calculatesthe far-end and near-end frame loss on the basis of the informationin the SLM message or the SLM protocol data unit (PDU).
A MEP maintains the following local counters for each test IDand for each peer MEP being monitored in a maintenance entity forwhich loss measurements are to be performed:
TxFCl—Number of synthetic frames transmitted towardthe peer MEP for a test ID. A source MEP increments this number forsuccessive transmission of synthetic frames with ETH-SLM request informationwhile a destination or receiving MEP increments this value for successivetransmission of synthetic frames with the SLR information.
RxFCl—Number of synthetic frames received from thepeer MEP for a test ID. A source MEP increments this number for successivereception of synthetic frames with SLR information while a destinationor receiving MEP increments it for successive reception of syntheticframes with ETH-SLM request information.
The following sections describe the phases of processing ofSLM 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 OpCodefield set as 55. The MEP generates a unique Test ID for the session,adds the source MEP ID, and initializes the local counters for thesession before SLM initiation. For each SLM PDU transmitted for thesession (test ID), the local counter TxFCl is sent in the packet.
No synchronization is required of the test ID value betweeninitiating and responding MEPs because the test ID is configuredat the initiating MEP, and the responding MEP uses the test ID itreceives from the initiating MEP. Because ETH-SLM is a sampling technique,it is less precise than counting the service frames. Also, the accuracyof measurement depends on the number of SLM frames used or the periodfor transmitting SLM frames.
Reception of SLMs and Transmission of SLRs
After the destination MEP receives a valid SLM frame from thesource MEP, an SLR frame is generated and transmitted to the requestingor source MEP. The SLR frame is valid if the MEG level and the destinationMAC address match the receiving MEP’s MAC address. All thefields in the SLM PDUs are copied from the SLM request except forthe following fields:
The source MAC address is copied to the destination MACaddress 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’sMEP ID.
TxFCb is saved with the value of the local counter RxFClat 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 framesreceived and also equal to the number of SLR frames sent. At the responderor 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 thesame TxTCf value) within the timeout value from its peer MEP. SLRframes that are received after the timeout value (5 seconds) arediscarded. With the information contained in SLR frames, a MEP determinesthe frame loss for the specified measurement period. The measurementperiod is a time interval during which the number of SLM frames transmittedis statistically adequate to make a measurement at a given accuracy.A MEP uses the following values to determine near-end and far-endframe loss during the measurement period:
Last received SLR frame's TxFCf and TxFCb values and thelocal counter RxFCl value at the end of the measurement period. These values are represented as TxFCf[tc], TxFCb[tc], and RxFCl[tc], wheretc is the end time of the measurement period.
SLR frame's TxFCf and TxFCb values of the first receivedSLR frame after the test starts and local counter RxFCl at the beginningof the measurement period. These values are represented as TxFCf[tp],TxFCb[tp], and RxFCl[tp], where tp is the start time of the measurementperiod.
For each SLR packet that is received, the local RxFCl counteris incremented at the sending or source MEP.
Computation of Frame Loss
Synthetic frame loss is calculated at the end of the measurementperiod on the basis of the value of the local counters and the informationfrom the last frame received. The last received frames contains theTxFCf 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.
Release
Description
16.1
Starting Junos OS Release16.1, the Ethernet loss measurement (ETH-LM) results are inaccuratewhen connectivity fault management (CFM) and performance monitoring(PM) PDUs received locally at a maintenance endpoint (MEP) as classifiedas belonging to the yellow class or a packet loss priority (PLP) ofmedium-high.
16.1
Starting with Junos OS Release 16.1, performance monitoringfor connectivity fault management (by including the performance-monitoring statement and its substatements at the [edit protocols oamethernet connectivity-fault-management] hierarchy level) isnot supported when the network-to-network (NNI) or egress interfaceis an aggregated Ethernet interface with member links on DPCs.
