Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Guide That Contains This Content
[+] Expand All
[-] Collapse All

    ITU-T Y.1731 ETH-LM, ETH-SLM, and ETH-DM on Aggregated Ethernet Interfaces Overview

    Starting with Junos OS Relase 15.2R1, 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 aggregated Ethernet (ae) interfaces. These ITU-T Y.1731 OAM services or performance monitoring techniques can be measured by on-demand mode (triggered through the CLI) or by proactive mode (triggered by the iterator application). These performance monitoring functionalities are supported on the following platforms:

    • MX Series routers with 16-port 10-Gigabit Ethernet MPCs and Trio-based FPCs (MPCs), where the same level of support for the Ethernet services OAM mechanisms on non-aggregated Ethernet interfaces is available on AE interfaces
    • MX2020 routers
    • ETH-DM is supported on MPC3E and MPC4E modules with only software timestamping
    • ETH-SLM is supported on MPC3E and MPC4E modules.

    Also, connectivity fault management (CFM) sessions established on the AE interfaces can be distributed to the Packet Forwarding Engine, apart from being handled on the Routing engine. This capability to distribute CFM sessions is useful in both scaled topologies and gracful Routing Engine switchover (GRES) for CFM sessions.

    Connectivity fault management (CFM) sessions operate in centralized mode over AE interfaces by default. Y.1731 performance monitoring (PM) is supported on centralized CFM sessions over AE interfaces. Also, distribution of CFM session over AE interfaces to line cards is supported from Junos OS Release 13.3. To enable the distribution of CFM sessions and to operate in centralized mode, include the ppm delegate-processing statement at the [edit routing-options ppm] hierarchy level. The mechanism that enables distribution of CFM sessions over AE interfaces provides the underlying infrastructure to support PM over AE interfaces. In addition, periodic packet management (PPM) handles time-sensitive periodic processing and performs such processes as sending process-specific packets and gathering statistics. With PPM processes running distributed on both the Routing Engine and the Packet Forwarding Engine, you can run performance monitoring processes on the Packet Forwarding Engine.

    For Ethernet delay measurement, hardware-assisted timestamping is supported on AE interfaces, similar to the support that exists on non-AE interfaces. Only hardware-based timestamping is supported because it is performed in the received path of the protocol data unit (PDU) packets, whereas software-based timestamping needs to be performed on the transmitted path and is not supported. For software timestamping, ETH-DM PDUs need to be transmitted and received on the same line card (same member of the AE interface). All the received ETH-DM PDUs are always redirected to the anchor Packet Forwarding Engine. In the transmission path, if the interface on the anchor Packet Forwarding Engine goes down, then the OAM pdus are redirected to one of the subordinate or member FPCs. Therefore, the processing of ETH-DM PDUs always occurs at the CPU of the line card or module that hosts the anchor Packet Forwarding Engine. ETH-DM is supported on AE interfaces with CCC, bridge, virtual private LAN service (VPLS), and inet address families. ETH-DM is supported for both active-active and active-standby modes of AE interfaces. For one-way delay measurement (1DM), the system clocks of the initiator MEP that transmits a request frame and the responder MEP that receives a reply frame need to be synchronized.

    For Ethernet loss measurement on AE interfaces, with the active-standby mode of the interfaces, transmission and reception of PDUs is always through the Packet Forwarding Engine that hosts the active link. For the active-standby mode of the AE interfaces, you can configure a maximum of only two member links. ETH-LM is supported only when all the active member or child links are on the same Packet Forwarding Engine. For the downstream maintenance endpoints (MEPs), ETH-LM is supported for CCC, VPLS, and bridge address families, and for upward MEPs, ETH-LM is supported only for CCC families. In the transmission path, with active-standby links of AE interfaces, whenever the active child link fails, if the standby link is non-local, the packets are redirected to the new active link. When this redirection occurs, the ETH-LM counters are reset. If the standby link is on same Packet Forwarding Engine as the active link, then the counters are not reset because the counters are read on the local Packet Forwarding Engine memory and to prevent the other end of the session to treat new Packet Forwarding Engine counters as losses owing to reset of the counters. In the received path, with active-standby links of AE interfaces, all the child links are programmed in the input list using next-hops to redirect the packets to the anchor FPC after copying the counters in the Packet Forwarding Engine. For Ethernet synthetic loss measurement (SLM), processing of SLM PDUs for requests and responses similar to other protocols from the line card CPU is implemented. All other computation and data are software-based. ETH-SLM is supported on AE interfaces for CCC, bridge, VPLS, and inet families.

    Before you can start an ETH-DM, ETH-LM, or ETH-SLM measurement sessions across an aggregated Ethernet service, you must configure two MX Series routers to support these measurement sessions. On each router, configure two physical or logical AE interfaces connected by a VLAN by including the interface ae-fpc/pic/port unit logical-unit-number vlan-id vlan-id statement at the [edit interfaces] hierarchy level and on each router, attach the peer MEPs to the interfaces by including the mep mep-id interface interface-name (protect | working) statement at the [edit protocols oam ethernet connectivity-fault-management maintenance-domain md-name maintenance-association ma-name] hierarchy level.

    Modified: 2016-01-28