OAM and SAA

Ethernet line loopbacks, being the lower layer functionality, take precedence over TWAMP operations. If an Ethernet port loopback is enabled, all frames including TWAMP frames are looped back. TWAMP frames cannot be processed on the interface until the loopback is released.

The following limitations apply:

• only the unauthenticated mode of TWAMP is supported. Authenticated and encrypted modes are excluded.

• TWAMP does not support redundant HA configurations. During a CSM activity switch, all TWAMP control sessions are dropped and all tests that are in progress are terminated.

TWAMP Light is supported on the same hardware as TWAMP. See 7705 SAR Support for TWAMP Server.

For information about how to configure the TWAMP Light reflector see the OAM commands for TWAMP Light.

Ethernet line loopbacks, being the lower layer functionality, take precedence over TWAMP Light operations. If an Ethernet port loopback is enabled, all frames are looped back. Frames cannot be processed on the interface until the loopback is released.

The 7705 SAR supports only the unauthenticated mode of TWAMP.

The following example shows a basic configuration using TWAMP Light to monitor two IP endpoints in a VPRN, including the default TWAMP Light values that were not overridden with configuration entries.

config>test-oam>twamp>twamp-light# info detail 
--------------------------------------------------------------------------
(default)      inactivity-timeout 100 
--------------------------------------------------------------------------
config>service>vprn# info 
--------------------------------------------------------------------------
            route-distinguisher 65535:500
            auto-bind-tunnel
                resolution-filter
                    ldp
                exit
                resolution filter
            exit
            vrf-target target:65535:5000
            interface "to-cpe31" create
                address 10.1.1.1/30
                sap 1/1/2:500 create
                exit
            exit
            static-route-entry 192.168.1.0/24 
                next-hop 10.1.1.2
                    no shutdown
                exit
            exit
            bgp
                no shutdown
            exit
            twamp-light
                reflector udp-port 64364 create
                    description "TWAMP Light reflector VPRN 500"
                    prefix 10.2.1.1/32 create
                        description "Process only 10.2.1.1 TWAMP Light Packets"
                    exit
                    prefix 172.16.1.0/24 create"
                        description "Process all 172.16.1.0 TWAMP Light packets"
                    exit
                    no shutdown
                exit
            exit
            no shutdown
----------------------------------------------

A 7705 SAR that process BGP 3107 labels always re-marks the TC bits. Ingress classification is based on the received TC/DSCP bits to FC. Egress re-marking is based on the QoS queue policy.

A 7705 SAR that does not process labels on a BGP route tunnel such as a 7705 SAR acting as an LSR, does not re-mark the TC bits.

Labeled BGP route tunnels pose a challenge to traceroute capability because there are two labels used in the transport layer: an inner BGP label identifying the far-end node and the regular label identifying the next hop for that far end.

Traceroute and TTL monitoring on the 7705 SAR have been enhanced to be able to identify and report every PE, ABR, ASBR, and P node along the path of a Layer 2 or Layer 3 service built partially or wholly over labeled BGP route tunnels.

Both the MPLS tunnel TTL and the labeled BGP route tunnel TTL are monitored for TTL expiry, which causes an ICMP TTL expired message to be sourced. Depending on the role of the intermediate nodes along the path, monitoring both TTL values is the most comprehensive way to ensure proper TTL handling.

Depending on how the network is built on elements in the topology, a node along the path might be operating based on the outer MPLS tunnel label or the inner BGP label. In order to ensure that all the nodes along the path are displayed correctly, the 7705 SAR sets the TTL of the outer MPLS transport tunnel and the inner labeled BGP route tunnel to identical values. The next node is therefore identified and displayed correctly in a traceroute regardless of which label it is operating on.

For a self-generated traffic traceroute, both the MPLS and the labeled BGP TTLs are set to 1 in order to identify the first node. At the next hop, both TTL values are incremented to 2. This pattern continues at each hop in the path.

The DDMAP TLV provides full validation for a BGP IPv4 label route tunneled over an RSVP LSP or an LDP FEC.

In order to properly check a target FEC that is stitched to another FEC (stitching FEC) of the same or a different type, or that is tunneled over another FEC (tunneling FEC), it is necessary for the responding nodes to provide details about the FEC manipulation to the sender node. The system collects this detailed information with the DDMAP TLV FEC stack change sub-TLV, shown in FEC Stack Change Sub-TLV. The field definitions match those of the DSMAP TLV and are described in RFC 4379.

The operation type specifies the action associated with the FEC stack change. FEC Stack Change Sub-TLV Operation Types defines the operation types for the FEC stack change sub-TLV.

When DDMAP TLV is configured on an LSP trace that does not undergo stitching or tunneling operation in the network, the procedures at the sender and responder nodes are the same as in the case of the existing DSMAP TLV.

When DDMAP TLV is configured on an LSP trace that does undergo stitching or tunneling operation in the network, there are changes to the target FEC stack validation procedures at the sender and responder nodes. The following procedure represent a superset of the rules described in Section 4 of RFC 6424 to allow greater scope of interoperability with other vendor implementations.

Responder Node Procedures:

1. As a responder node, the 7705 SAR always inserts the global return code, 3 Replying router is an egress for the FEC at stack-depth <RSC> or the code, 14 See DDMAP TLV for Return Code and Return Subcode.

2. When the responder node inserts a global return code of 3, it does not include a DDMAP TLV.

3. When the responder node includes the DDMAP TLV, it inserts the global return code, 14 See DDMAP TLV for Return Code and Return Subcode. Additionally, the responder node will:

   1. on a success response, include a return code of 15 in the DDMAP TLV for each downstream hop that has a FEC stack change sub-TLV

   2. on a success response, include a return code, 8 Label switched at stackdepth <RSC> in the DDMAP TLV for each downstream hop if no FEC stack change sub-TLV is present

   3. on a failure response, include an appropriate error return code in the DDMAP TLV for each downstream hop

4. A tunneling node indicates that it is pushing a FEC (the tunneling FEC) on top of the target FEC stack TLV by including a FEC stack change sub-TLV in the DDMAP TLV with a FEC operation type value of PUSH. It also includes a return code, 15 Label switched with FEC change. The downstream interface address and downstream IP address fields of the DDMAP TLV are populated for the pushed FEC. The remote peer address field in the FEC stack change sub-TLV is populated with the address of the control plane peer for the pushed FEC. The Label stack sub-TLV provides the full label stack over the downstream interface.

5. A node that is stitching a FEC indicates that it is performing a POP operation for the stitched FEC followed by a PUSH operation for the stitching FEC and potentially one PUSH operation for the transport tunnel FEC. The echo reply message will include two or more FEC stack change sub-TLVs in the DDMAP TLV. It also includes a return code 15 Label switched with FEC change. The downstream interface address and downstream address fields of the DDMAP TLV are populated for the stitching FEC. The remote peer address field in the FEC stack change sub-TLV of type POP is populated with a null value (0.0.0.0). The remote peer address field in the FEC stack change sub-TLV of type PUSH is populated with the address of the control plane peer for the tunneling FEC. The Label stack sub-TLV provides the full label stack over the downstream interface.

6. If the responder node is the egress for one or more FECs in the target FEC Stack, then it must reply with no DDMAP TLV and with a return code 3 Replying router is an egress for the FEC at stack-depth <RSC>. RSC must be set to the depth of the topmost FEC. This operation is iterative.

   The receipt of the echo reply message the sender node will pop the topmost FEC from the target stack FEC TLV and resend the echo request message with the same TTL value as explained in step 5. The responder node performs the same operation until all FECs are popped or until the topmost FEC in the target FEC stack TLV matches the tunneled or stitched FEC. In the latter case, processing of the target FEC stack TLV follows again steps 1 or 2.

Sender Node Procedures:

1. If the echo reply message contains the return code 14 See DDMAP TLV for Return Code and Return Subcode and the DDMAP TLV has a return code 15 Label switched with FEC change, the sender node adjusts the target FEC Stack TLV in the echo request message for the next value of the TTL to reflect the operation on the current target FEC stack as indicated in the FEC stack change sub-TLV received in the DDMAP TLV of the last echo reply message. This results in one FEC being popped at most and one or more FECs being pushed as indicated.

2. If the echo reply message contains the return code 3 Replying router is an egress for the FEC at stack-depth <RSC>, then:

   1. If the value for the label stack depth specified in the Return Sub-Code (RSC) field is the same as the depth of current target FEC Stack TLV, then the sender node considers the trace operation complete and terminates it. A 7705 SAR responder node will cause this case to occur as per Step 6 of the Responder Node Procedures.

   2. If the value for the label stack depth specified in the Return Sub-Code (RSC) field is different from the depth of the current target FEC Stack TLV, the sender node must continue the LSP trace with the same TTL value after adjusting the target FEC stack TLV by removing the top FEC.

      This step continues iteratively until the value for the label stack depth specified in the Return Sub Code (RSC) field is the same as the depth of current target FEC Stack TLV, at which point step a is performed. A 7705 SAR responder node causes this case to occur as per Step 6 of the responder node procedures.

   3. If a DDMAP TLV with or without a FEC stack change sub-TLV is included, then the sender node ignores it and processing is performed as per steps (a) or (b) above. A 7705 SAR responder node does not cause this case to occur but a third party implementation may.

3. As a sender node, the 7705 SAR can accept an echo-reply message with the global return code of either 14 (with DDMAP TLV return code of 15 or 8), or 15 and process the FEC stack change TLV as per Step 1 of the Sender Node Procedures.

4. If an LSP ping is performed directly to the egress LER of the stitched FEC, there is no DDMAP TLV included in the echo request message and the responder node, which is the egress node, still replies with return code 4 Replying router has no mapping for the FEC at stack- depth <RSC>. This case cannot be resolved with this feature.

BGP 3107 Tunnel Through LDP FEC and the following LSP trace examples illustrate how the 7705 SAR provides validation for a BGP IPv4 label route tunneled over an RSVP LSP or an LDP FEC.

LSP trace launched from ALU-A (AS 100) to ALU-D (AS 300) with the DSMAP option:

ALU-A# oam lsp-trace bgp-label prefix 10.20.1.4/32 downstream-map-tlv dsmap src-ip-
address 10.20.1.1 
lsp-trace to 10.20.1.4/32: 0 hops min, 0 hops max, 104 byte packets
1  10.20.1.3  rtt=3.63ms rc=8(DSRtrMatchLabel)
2  10.20.1.5  rtt=9.04ms rc=8(DSRtrMatchLabel)
3  10.20.1.6  rtt=7.73ms rc=8(DSRtrMatchLabel) rsc=1 
4  10.20.1.4  rtt=1.62ms rc=3(EgressRtr) rsc=1 

LSP trace launched from ALU-A (AS 100) to ALU-D (AS 300) with the DDMAP option:

ALU-A# oam lsp-trace bgp-label prefix 10.20.1.4/32 downstream-map-tlv ddmap src-ip-
address 10.20.1.1 
lsp-trace to 10.20.1.4/32: 0 hops min, 0 hops max, 124 byte packets
1  10.20.1.3  rtt=9.29ms rc=8(DSRtrMatchLabel) rsc=2 
2  10.20.1.5  rtt=3.69ms rc=8(DSRtrMatchLabel) rsc=2 
3  10.20.1.6  rtt=2.81ms rc=3(EgressRtr) rsc=2 
3  10.20.1.6  rtt=11.5ms rc=8(DSRtrMatchLabel) rsc=1 
4  10.20.1.4  rtt=1.68ms rc=3(EgressRtr) rsc=1 

LSP trace launched from ALU-B (AS 300) to ALU-F (AS 100) with the DSMAP option:

ALU-B# oam lsp-trace bgp-label prefix 10.20.1.6/32 downstream-map-tlv dsmap src-ip-
address 10.20.1.2 
lsp-trace to 10.20.1.6/32: 0 hops min, 0 hops max, 104 byte packets
1  10.20.1.1  rtt=5.39ms rc=8(DSRtrMatchLabel) rsc=1 
2  10.1.3.2  * 
3  10.1.3.2  * 
4  10.20.1.6  rtt=1.27ms rc=10(DSRtrUnmatchLabel) rsc=1 

LSP trace launched from ALU-B (AS 300) to ALU-F (AS 100) with the DDMAP option:

ALU-B# oam lsp-trace bgp-label prefix 10.20.1.6/32 downstream-map-tlv ddmap src-ip-
address 10.20.1.2 
lsp-trace to 10.20.1.6/32: 0 hops min, 0 hops max, 108 byte packets
1  10.20.1.1  rtt=10.8ms rc=15(LabelSwitchedWithFecChange) rsc=1 
2  10.1.3.2  * 
3  10.0.0.2  * 
4  10.20.1.6  rtt=1.29ms rc=3(EgressRtr) rsc=2 
4  10.20.1.6  rtt=1.23ms rc=5(DSMappingMismatched) rsc=1 

VCCV creates an IP control channel within the pseudowire between PE1 and PE2 (see VCCV Ping Application). PE2 should be able to distinguish, on the receive side, VCCV control messages from user packets on that VLL.

VCCV-based pseudowire (PW) tests are only supported on dynamically signaled PWs (not on statically signaled PWs).

There are three methods of encapsulating a VCCV message in a VLL, which translates into three types of control channels, as follows:

• Type 1 — in-band VCCV (special control word)

  Type 1 uses the OAM control word, which is shown in OAM Control Word Format.

  

  In OAM Control Word Format, the first nibble is set to 0x1. The Format ID and the Reserved fields are set to 0 and the Channel Type is the code point associated with the VCCV IP control channel, as specified in the PWE3 IANA registry [RFC 4446]. The channel type value of 0x21 indicates that the Associated Channel carries an IPv4 packet.

  The use of the OAM control word assumes that the draft-martini control word is also used for the user packets. This means that if the control word is optional for a VLL and is not configured, the 7705 SAR PE node will only advertise the router alert label as the CC capability in the Label Mapping message.

  This method is supported by the 7705 SAR.

• Type 2 — out-of-band VCCV (router alert above the service label)

  The 7705 SAR uses the router alert label immediately above the VC label to identify the VCCV ping message. This method has a drawback in that if ECMP is applied to the outer LSP label, such as the transport label, the VCCV message will not follow the same path as the user packets. This effectively means it will not troubleshoot the appropriate path.

  This method is supported by the 7705 SAR when a 7750 SR node acts as an LSR in the core of the network. If a 7705 SAR acts as an LSR in the core of the network, the VCCV type 2 message will instead follow the data path.

• Type 3 — TTL expiry VCCV (service label TTL = 1 and special control word)

  This method is not supported by the 7705 SAR.

When sending the label mapping message for the VLL, PE1 and PE2 must indicate which of the above OAM packet encapsulation methods (that is, which control channel type) they support. This is accomplished by including an optional VCCV TLV in the PW FEC interface parameter field. The format of the VCCV TLV is shown in VCCV TLV.

The absence of the optional VCCV TLV in the Interface parameters field of the pseudowire FEC indicates that the PE has no VCCV capability.

In VCCV TLV, the Control Channel (CC) Type field is a bit mask used to indicate if the PE supports none, one, or many control channel types:

• 0x00 — none of the following VCCV control channel types (Type 1, Type 2, or Type 3) are supported

• 0x01 — (Type 1, in-band) PWE3 OAM control word (see OAM Control Word Format)

• 0x02 — (Type 2, out-of-band) MPLS router alert label

• 0x04 — (Type 3, not supported on the 7705 SAR) MPLS inner label TTL = 1

If both PE nodes support more than one of the CC types, a 7705 SAR PE will make use of the CC type with the lowest type value. For instance, OAM control word (0x01) will be used in preference to the MPLS router alert label (0x02).

The Connectivity Verification (CV) Type field is a bit mask used to indicate the specific type of VCCV packets to be sent over the VCCV control channel. The possible values supported on the 7705 SAR are:

• 0x00 — none of the following VCCV packet types are supported

• 0x02 — LSP ping

  This value (0x02) is used in the VCCV ping application and applies to a VLL over an MPLS, GRE, or IP SDP.

A VCCV ping is an LSP echo request message as defined in RFC 4379. It contains a Layer 2 FEC stack TLV in which it must include the sub-TLV type 10 FEC 128 pseudowire. It also contains a field that indicates to the destination PE which reply mode to use:

• do not reply

  This mode is supported by the 7705 SAR.

• reply by an IPv4 UDP packet

  This mode is supported by the 7705 SAR.

• reply via an IPv4 UDP packet with router alert

  This mode is not supported by the 7705 SAR.

  Note: This mode, which sets the router alert bit in the IP header, should not be confused with the CC type that makes use of the router alert label.

• reply by application-level control channel

  This mode sends the reply message in-band over the pseudowire from PE2 to PE1. PE2 will encapsulate the echo reply message using the CC type negotiated with PE1.

  This mode is supported by the 7705 SAR.

The VCCV ping reply has the same format as an LSP echo reply message as defined in RFC 4379. The message is sent via the reply mode requested by PE1. The return codes supported are the same as those currently supported in the 7705 SAR LSP ping capability.

The VCCV ping feature is in addition to the service ping OAM feature that can be used to test a service between 7705 SAR nodes. The VCCV ping feature can test connectivity of a VLL with any third-party node that is compliant with RFC 5085.

VCCV Ping Over a Multi-Segment Pseudowire displays an example of an application of VCCV ping over a multi-segment pseudowire (MS-PW). Pseudowire switching provides the user with the ability to create a VLL service by cross-connecting two spoke SDPs.

In the network, a Termination PE (T-PE) is where the pseudowire originates and terminates. The Switching PE (S-PE) is the node that performs pseudowire switching by cross-connecting two spoke SDPs.

VCCV ping on the 7705 SAR is capable of performing VCCV ping to a destination PE. A VLL FEC ping is a message sent by T-PE1 to test the FEC at T-PE2. The operation at T-PE1 and T-PE2 is the same as in the case of a single-segment pseudowire. The 7705 SAR pseudowire switching node, S-PE1, pops the outer label, swaps the inner (VC) label, decrements the TTL of the VC label, and pushes a new outer label. The 7705 SAR S-PE1 node does not process the VCCV OAM control word unless the VC label TTL expires. If the VC label TTL expires, the message is sent to the CSM for further validation and processing. This is the method described in draft-hart-pwe3-segmented-pw-vccv.

The originator of the VCCV ping message does not need to be a T-PE node; it can be an S-PE node. The destination of the VCCV ping message can also be an S-PE node. When an S-PE node receives a VCCV ping echo request destined for itself, it sends an IP-routed reply. VCCV trace can trace the entire path of a pseudowire with a single command issued at the T-PE. This is equivalent to LSP trace and is an iterative process, where T-PE1 sends successive VCCV ping messages while incrementing the TTL value, starting from TTL=1.

The procedure for each iteration is the same. Each node in which the VC label TTL expires checks the FEC and replies with the FEC to the downstream S-PE or T-PE node. The process is terminated when the reply is sent from the T-PE2 node or when a timeout occurs.

Although tracing of the MS-PW path is possible using the methods described in the VCCV Ping section, these require multiple manual iterations and that require the FEC of the last pseudowire segment to the target T-PE/S-PE already be known at the node originating the echo request message for each iteration. This mode of operation is referred to as a "ping" mode.

The automated VCCV trace can trace the entire path of a pseudowire with a single command issued at the T-PE or at an S-PE. This is equivalent to LSP trace and is an iterative process by which the ingress T-PE or T-PE sends successive VCCV ping messages with incrementing TTL values, starting from TTL=1.

The method is described in draft-hart-pwe3-segmented-pw-vccv, VCCV Extensions for Segmented Pseudo-Wire, and is pending acceptance by the PWE3 working group. In each iteration, the source T-PE or S-PE builds the MPLS echo request message in a way similar to VCCV Ping. The first message with TTL=1 will have the next-hop S-PE T-LDP session source address in the Remote PE Address field in the pseudowire FEC TLV. Each S-PE that terminates and processes the message will include the FEC 128 TLV corresponding to the pseudowire segment to its downstream node, in the MPLS echo reply message. The inclusion of the FEC TLV in the echo reply message is allowed according to RFC 4379, Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures.

The source T-PE or S-PE then sends the next echo reply message with TTL=2 to test the next-next hop for the MS-PW. It copies the FEC TLV it received in the echo reply message into the new echo request message. The process is terminated when the reply is sent from the egress T-PE node or when a timeout occurs. If specified, the max-ttl parameter in the vccv-trace command will stop on SPE before reaching T-PE.

The results of VCCV trace can be displayed for fewer pseudowire segments of the end-to-end MS-PW path. In this case, the min-ttl and max-ttl parameters are configured accordingly. However, the T-PE/S-PE node will still probe all hops up to the min-ttl value in order to correctly build the FEC of the required subset of segments.

This method does not require the use of the downstream mapping TLV in the echo request and echo reply messages.

MS-PW is supported with a mix of static and signaled pseudowire segments. However, VCCV ping and VCCV trace are not allowed if any segment of the MS-PW is static. Users cannot test a static segment or contiguous signaled segments of the MS-PW. VCCV ping and VCCV trace are not supported in static-to-dynamic configurations.

VCCV is supported on S-PE nodes configured for MS-PW and PW redundancy. In this case, S-PE terminates the in-band or out-of-band (IP-routed) VCCV ping (echo reply) and can generate VCCV ping (echo request) toward the dynamic section of the PW segment.

To configure an S-PE for MS-PW and pseudowire redundancy, an explicit endpoint is required to configure the service. Only one explicit endpoint is supported. The first PW segment must be configured with a static inner label under an implicit endpoint. The second PW segment can be created as either a redundant or non-redundant PW using the explicit endpoint.

On S-PE nodes configured for MS-PW and PW redundancy, each segment of the PW can be configured with its own independent control word. The control word of the dynamic segment does not have to match the control word of the static segment for traffic to flow. The control word is automatically inserted or removed from the packets as they are switched from one segment to the other based on the control word configuration for each segment.

From an OAM diagnostic perspective, only Type-1 VCCV is supported for the dynamic MS-PW segment, which means that the PW segment must be configured with the control word option. In this mode, the ability to support VCCVs is signaled through the label message and the optional VCCV TLV toward the dynamic segment on the S-PE. The S-PE terminates all VCCV packets arriving on the dynamic segment, then extracts them toward the CSM.

In VCCV Ping Over a Multi-Segment Pseudowire, a trace can be performed on the MS-PW originating from T-PE1 by a single operational command. The following process occurs:

1. T-PE 1 sends a VCCV echo request with TTL set to 1 and a FEC 128 containing the pseudowire information of the first segment (pseudowire1 between T-PE 1 and S-PE) to S-PE for validation.

2. S-PE validates the echo request with the FEC 128. Since it is a switching point between the first and second segment, it builds an echo reply with a return code of 8 and includes the FEC 128 of the second segment (pseudowire2 between S-PE and T-PE 2) and sends the echo reply back to T-PE 1.

3. T-PE 1 builds a second VCCV echo request based on the FEC 128 in the echo reply from the S-PE. It increments the TTL and sends the next echo request out to T-PE 2. The VCCV echo request packet is switched at the S-PE datapath and forwarded to the next downstream segment without any involvement from the control plane.

4. T-PE 2 receives and validates the echo request with the FEC 128 of the pseudowire2 from TPE 1. Since T-PE 2 is the destination node or the egress node of the MS-PW, it replies to T-PE1 with an echo reply with a return code of 3 (egress router) and no FEC 128 is included.

5. T-PE 1 receives the echo reply from T-PE 2. T-PE 1 is made aware that T-PE 2 is the destination of the MS-PW because the echo reply does not contain the FEC 128 and because its return code is 3. The trace process is completed.

7705 SAR Ethernet OAM Endpoints illustrates the complementary use of dot3ah and dot1ag to locate points of failure along a route from BTS to BSC. Because dot1ag and Y.1731 have similar functions, only dot1ag is discussed in order to simplify the explanation.

In 7705 SAR Ethernet OAM Endpoints, from the IP/MPLS (network) layer perspective, the 7705 SAR looks as though it is connected directly to the 7750 SR. From the Ethernet (transport) layer perspective, the route passes through many ports and nodes, where each port or node is a potential point of failure. These failure points cannot be detected using IP/MPLS OAM capabilities (that is, using ETH-CFM (dot1ag)). However, they can be detected using EFM OAM (dot3ah) capabilities.

Dot3ah uses port-level loopbacks to check and verify last-mile Ethernet frame integrity, connectivity verification between ports and nodes, and so on. As shown in 7705 SAR Ethernet OAM Endpoints, dot3ah provides transport (link) layer OAM between the BTS and the 7705 SAR access port facing the BTS (ports A and B), or between the 7705 SAR network port and the MEN switch (ports C and D). Ethernet first mile (EFM) OAM allows users to test frame integrity and detect Ethernet layer failures faster than using associated heartbeat messages.

Dot1ag checks end-to-end connectivity across an Ethernet PW (across a network). Because end-to-end connectivity differs depending on the service provided and the span of the network, dot1ag can operate at several MD levels (as defined in the IEEE 802.1ag standard). For example, in 7705 SAR Ethernet OAM Endpoints, ETH-CFM (dot1ag) could be used by a MEN provider at one MD level to ensure connectivity between ports D and I (or possibly all the way to their customer's Ethernet ports, C and J). Similarly, a mobile backhaul service provider (MBSP) can use dot1ag at another MD level to ensure connectivity between ports B and K (and possibly between ports A and L).

ETH-CFM (Dot1ag) Capabilities on the 7705 SAR and EFM OAM (Dot3ah) Capabilities on the 7705 SAR illustrate the use of ETH-CFM to verify connectivity across an Ethernet PW and EFM OAM to verify transport layer connectivity between two directly connected nodes.

For example, in ETH-CFM (Dot1ag) Capabilities on the 7705 SAR, an MBSP can use dot1ag between the two Ethernet spoke SDP endpoints (ports C and J, which define the Ethernet PW) to ensure connectivity. Similarly, a MEP can use dot1ag between ports D and I to ensure the health status of the Ethernet (virtual) private line.

In EFM OAM (Dot3ah) Capabilities on the 7705 SAR, EFM OAM ensures transport layer connectivity between two directly connected nodes. EFM OAM (Dot3ah) Capabilities on the 7705 SAR illustrates three scenarios in which EFM can be used by the MEN provider to ensure error-free connectivity to the 7705 SAR (the cell site) via loopback tests, including:

• scenario 1: EFM termination at the Ethernet access port, which includes loopback tests, heartbeat messages at the Ethernet layer with dying gasp, and termination of customer device-initiated EFM packets at the access port

• scenario 2: EFM termination at the Ethernet network port, which includes network-side loopbacks

• scenario 3: EFM tunneling through an Epipe service

The hold MEP up on failure function allows MEP operation that is independent of SAP status. In order to report service-level agreement (SLA) metrics, transport providers run Y.1731 performance monitoring tests periodically. At preset times, transport providers initiate various tests to measure and record one or all required SLA components: jitter, delay, loss, and throughput. The ability to hold MEP up allows the MEP to be kept in operation even if the SAP is down or non-operational.

The hold MEP up on failure function applies only to Ethernet pseudowire services (Epipes) operating between SAPs or between SAPs and SDPs. The SAP connecting the provider equipment to the customer can be configured to hold the MEP in operation when the customer-facing SAP enters any failed state. Only one SAP per Epipe can be configured in this manner. Pseudowire status will indicate a failed SAP in the LDP status message, but as long as the pseudowire is in an operationally up state, it supports receiving frames from the network's far-end side. Counters are also incremented to accurately represent the number of received packets.

ETH-CFM PM measurements, ETH-CFM troubleshooting tools and connectivity, and ETH-CFM CCM processing and fault propagation are not impacted by this feature and continue to function normally.

The loopback function is supported by 802.1ag and Y.1731 on the 7705 SAR. A Loopback Message (LBM) is generated by a MEP to its peer MEP. Both dot1ag and dot3ah loopbacks are supported. The loopback function is similar to IP or MPLS ping in that it verifies Ethernet connectivity between the nodes on a per-request basis. That is, it is non-periodic and is only initiated by a user request.

In Dot1ag Loopback Test, the line labeled LB represents the dot1ag loopback message between the 7750 SR (source) and 7705 SAR (target) over an Ethernet PW (Epipe). The 7750 SR-generated LBM is switched to the 7705 SAR, where the LBM is processed. After the 7705 SAR generates the Loopback Reply message (LBR), the LBR is switched over the Epipe to the 7750 SR.

ETH-LB tests are run using the oam>eth-cfm>loopback command.

The linktrace function is supported by 802.1ag and Y.1731 on the 7705 SAR. A Linktrace Message (LTM) is originated by a MEP and targeted to a peer MEP in the same MA and within the same MD level. Its function is similar to IP traceroute. The peer MEP responds with a Linktrace Reply (LTR) message after successful inspection of the LTM.

ETH-LT tests are run using the oam>eth-cfm>linktrace command.

Throughput measurement is performed by sending frames to the far end at an increasing rate (up to wire speed) and measuring the percentage of frames received back. In general, the rate is dependent on frame size; the larger the frame size, the lower the rate.

The Y.1731 specification recommends the use of unicast ETH-LB and ETH-Test frames to measure throughput.

On the 7705 SAR, LBM processing and LBR generation is enhanced and occurs on the datapath, allowing the node to respond to loopback messages at wire speed and making in-service throughput tests possible. Therefore, if the 7705 SAR receives LBMs at up to wire speed, it can generate up to an equal number of LBRs. In order to process LBMs at wire speed, there must be either no TLVs or a single TLV (which is a data TLV) in the LBM frame. The End TLV field (0) must be present and the frame can be padded with data after the End TLV field in order to increase the size of the frame. The MAC address cannot be a multicast MAC address; it must be the MEP MAC destination address (DA).

Datapath processing of LBMs is supported with dot1ag and Y.1731 for the following MEPs:

• SAP Up and Down MEPs

• spoke SDP Up and Down MEPs

• mesh SDP Up and Down MEPs (VPLS only)

For spoke or mesh SDP Up and Down MEPs, fastpath (datapath) LBM processing requires that both interfaces—the LBM receiver and the LBR transmitter—reside on the same adapter card. For example, if the 7705 SAR must perform a reroute operation and needs to move the next hop interface to another adapter card (that is, LBMs are received on one card and LBRs are transmitted on another), the fastpath processing of LBMs is terminated and LBM processing continues via the CSM.

The continuity check function is supported by 802.1ag and Y.1731 on the 7705 SAR. A Continuity Check Message (CCM) is a multicast frame that is generated by a MEP and sent to its remote MEPs in the same MA. The CCM does not require a reply message. To identify faults, the receiving MEP maintains a MEP database with the MAC addresses of the remote MEPs with which it expects to maintain connectivity checking. The MEP database can be provisioned manually. If there is no CCM from a monitored remote MEP in a preconfigured period, the local MEP raises an alarm.

Continuity checks are enabled using the eth-cfm>mep>ccm-enable command for Epipe and VPLS services and for router network interfaces.

The following CC capabilities are supported:

• enable and disable CC for a MEP

• automatically put local MEPs into the database when they are created

• manually configure and delete the MEP entries in the CC MEP monitoring database. The only local provisioning required to identify a remote MEP is the remote MEP identifier (using the remote-mepid mep-id command).

• CCM transmit interval: 10ms, 100ms, 1s, 10s, 1m, 10m (default: 10s)

• transmit interval: 10ms, 100ms, 1s, 10s, 1m, 10m (default: 10s)

• CCM declares a fault when it:

  • stops hearing from one of the remote MEPs for a period of 3.5 times the CC interval

  • hears from a MEP with a lower MD level

  • hears from a MEP that is not in the same MA

  • hears from a MEP that is in the same MA but is not in the configured MEP list

  • hears from a MEP that is in the same MA with the same MEP ID as the receiving MEP

  • recognizes that the CC interval of the remote MEP does not match the local configured CC interval

  • recognizes that the remote MEP declares a fault

    An alarm is raised and a trap is sent if the defect is greater than or equal to the configured low-priority-defect value.

• CC must be enabled in order for RDI information to be carried in the CCM OAMPDU

The optional ccm-tlv-ignore command can be used to ignore the receipt of interface-status and port-status TLVs in the ETH-CCM PDU on a facility MEP. No processing is performed on ignored ETH-CCM TLV values.

Any TLV that is ignored is reported as absent to the relevant remote peer, and the values in the TLV do not have any effect. This is the same behavior as if the received ETH-CCM PDU never included these TLVs in the first place. If the TLV is not properly formed, the ETH-CCM PDU will fail the packet parsing process, which will cause it to be discarded and an alarm to be raised.

The Ethernet Remote Defect Indication function (ETH-RDI) is used by a MEP to communicate to its peer MEPs that a defect condition has been encountered. Defect conditions such as signal failure and AIS may result in the transmission of frames with ETH-RDI information. ETH-RDI is used only when ETH-CC transmission is enabled and it is enabled automatically.

ETH-RDI has the following two applications:

• single-ended fault management — the receiving MEP detects an RDI defect condition, which gets correlated with other defect conditions in this MEP. The absence of received ETH-RDI information in a single MEP indicates the absence of defects in the entire MEG.

• contribution to far-end performance monitoring — the transmitting MEP reflects that there was a defect at the far end, which is used as an input to the performance monitoring process

A MEP that is in a defect condition transmits frames with ETH-RDI information. A MEP, upon receiving frames with ETH-RDI information, determines that its peer MEP has encountered a defect condition.

The specific configuration information required by a MEP to support the ETH-RDI function is as follows:

• MEG level — the MEG level at which the MEP exists

• ETH-RDI transmission period — application-dependent and is the same value as the ETH-CC transmission period

• priority — the priority of frames containing ETH-RDI information and is the same value as the ETH-CC priority

The PDU used to carry ETH-RDI information is the CCM.

The Ethernet Alarm Indication Signal function (ETH-AIS) is a Y.1731 CFM enhancement used to suppress alarms at the client (sub) layer following detection of defect conditions at the server (sub) layer.

Transmission of frames with ETH-AIS information can be enabled or disabled on a Y.1731 SAP MEP.

ETH-AIS is enabled using the eth-cfm>mep>ais-enable command for Epipe and VPLS services.

Frames with ETH-AIS information can be issued at the client MEG level by a MEP, including a server MEP, upon detecting the following conditions:

• signal failure conditions in the case where ETH-CC is enabled

• AIS condition in the case where ETH-CC is disabled

For a point-to-point Ethernet connection at the client (sub) layer, a client layer MEP can determine that the server (sub) layer entity providing connectivity to its peer MEP has encountered a defect condition upon receiving a frame with ETH-AIS information. Alarm suppression is simplified by the fact that a MEP is expected to suppress only those defect conditions associated with its peer MEP.

Only a MEP, including a server MEP, is configured to issue frames with ETH-AIS information. Upon detecting a defect condition, the MEP can immediately start transmitting periodic frames with ETH-AIS information at a configured client MEG level. A MEP continues to transmit periodic frames with ETH-AIS information until the defect condition is removed. Upon receiving a frame with ETH-AIS information from its server (sub) layer, a client (sub) layer MEP detects the AIS condition and suppresses alarms associated with all its peer MEPs. After the AIS condition is cleared, a MEP resumes alarm generation upon detecting defect conditions.

The following specific configuration information is required by a SAP MEP to support ETH-AIS:

• client MEG level — the MEG level at which the most immediate client layer MEPs exist

• ETH-AIS transmission period — the transmission period of frames with ETH-AIS information

• priority — the priority of frames with ETH-AIS information

The Ethernet Test (signal) function (ETH-Test) is a Y.1731 CFM enhancement used to perform one-way, on-demand, in-service diagnostics tests, which include verifying frame loss and bit errors. ETH-Test is supported on Y.1731 SAP MEPs and facility MEPs on network interfaces.

ETH-Test is enabled using the eth-cfm>mep>eth-test-enable command for Epipe and VPLS services and for router network interfaces and is run using the oam>eth-cfm>eth-test command.

When configured to perform such tests, a MEP inserts frames with ETH-Test information such as frame size and transmission patterns.

When an in-service ETH-Test function is performed, data traffic is not disrupted and the frames with ETH-Test information are transmitted.

To support ETH-Test, a Y.1731 SAP or facility MEP requires the following configuration information:

• MEG level — the MEG level at which the MEP exists

• unicast MAC address — the unicast MAC address of the peer MEP for which the ETH-Test is intended

• data — an optional element with which to configure data length and contents for the MEP. The contents can be a test pattern and an optional checksum.

  Examples of test patterns include all 0s or all 1s. At the transmitting MEP, this configuration information is required for a test signal generator that is associated with the MEP. At the receiving MEP, this configuration is required for a test signal detector that is associated with the MEP.

• priority — the priority of frames with ETH-Test information

A MEP inserts frames with ETH-Test information toward a targeted peer MEP. The receiving MEP detects the frames with ETH-Test information and performs the requested measurements.

The Y.1731 recommendation covers the following performance parameters, which are based on Metro Ethernet Forum (MEF) 10:

• frame delay — specified as one-way or round-trip delay for a frame, where frame delay is defined as the time elapsed since the start of transmission of the first bit of the frame by a source node until the reception of the frame by the destination node or the same source node

• frame delay variation — a measure of the variations in the frame delay between a pair of service frames, where the service frames belong to the same CoS instance on a point-to-point Ethernet connection

The performance parameters listed above are applicable to Ethernet services frames. Services frames are those frames that conform to an agreed-upon level of bandwidth profile conformance and are associated with a particular CoS identifier. Services frames are admitted at the ingress Ethernet flow point of a point-to-point Ethernet connection and should be delivered to the egress Ethernet flow point.

The 7705 SAR supports one-way and two-way Ethernet Delay Measurement (ETH-DM) tests (section 8.2 of the Y.1731 standard). The tests are run using the oam>eth-cfm>one-way-delay-test and oam>eth-cfm>two-way-delay-test commands. Ethernet Delay Variation (ETH-DV) tests are run concurrently with the one-way and two-way ETH-DM tests.

For ETH-DM, the accuracy of the measurement is in the microseconds range.

Y.1731 delay measurement implementation ensures the most accurate results under all circumstances. The implementation ensures that there is minimal delay measurement error between packet generation and packet play-out over the Ethernet link.

In order to isolate delay measurement results from the effects of any queuing, scheduling, and shaping procedures, timestamping of source one-way and two-way delay measurement (1DM and DMM) frames in the transmit direction occurs when the first byte of the DM frame is put on the wire (that is, once the actual serialization starts). Last-minute timestamping ensures that DM tests truly measure the delay between two SAP, spoke SDP, mesh SDP, or port endpoints, and not the delay imposed by the routers. Using these accurate measurements, a network operator can separate the delay introduced by the routers from the transmission delay introduced by the transmission network, such as a Metro Ethernet network (MEN) or Generic Framing Procedure (GFP) over SONET links.

Timestamping of received 1DM and DMM frames is similar to transmitted source 1DM and DMM frames. When a Y.1731 delay measurement frame is identified internally, it is immediately timestamped to ensure reporting of only the network-induced delay and jitter.

With two-way delay measurement, delay measurement reply (DMR) timestamping occurs at the entry point to the egress datapath. DMR frames are then classified according to their configured dot1p setting and experience any scheduling delays experienced by the queue and scheduling priorities that the frames are associated with. Performing DMR timestamping at the entry point to the egress datapath provides the most accurate end-to-end measurement of delay and jitter, as it takes into account the internal delay of the responding node due to other higher-priority packets.

In summary, one-way delay measurement performs timestamping in the transmit direction only when the frame is about to be sent on the wire and in the receive direction when the frame is received, before any queuing at the far end. This provides true transport network-induced delay and jitter measurements. Two-way delay measurement takes into account the delay introduced by queuing and scheduling of the far-end node for true end-to-end measurements.

The 7705 SAR supports single-ended and dual-ended Ethernet Loss Measurement (ETH-LM) tests. Single-ended LM tests are run using the oam>eth-cfm>single-ended-loss-test command and are considered on-demand tests. Dual-ended LM tests are enabled using the eth-cfm>mep>dual-ended-loss-test-enable command for Epipe services and network router interfaces. When enabled, dual-ended LM tests run continuously in the background.

Y.1731 loss measurement functionality is implemented to ensure the most accurate results under all circumstances. Each adapter card has a network processor (NP). LM counters are maintained at the NP. The NP is responsible for incrementing and resetting these counters. These counters are accessed by the CSM CPU in order to calculate and display the loss (percentage) to the user.

LM/CCM frames follow the associated QoS path and therefore might inadvertently report loss due to local congestion even before the frame is switched onto the link. In order to reflect the true experience of a particular QoS setting, generated LM/CCM frames follow the egress QoS path. Once generated, these frames are classified in the same manner as the applicable dot1p-to-FC mapping, associated queuing, and scheduling rules. Following the proper path ensures that loss measurements reflect the experience of a given FC all the way through the network, including within the 7705 SAR platform. As is the case for any other frame of the same FC (that is, user or control frame), the LM/CCM frame follows the associated QoS path to reflect the real experience.

For example, newly generated LM/CCM frames that have a higher counter value can be forwarded sooner than LM/CCM frames with a lower counter value that have been generated but are waiting to be serviced (that is, frames with a lower queue, a queue in the out-of-profile state; or a single SAP with multiple FCs). As a result, when under congestion, the LM ratio would increase to reflect local loss if lower-priority frames cannot be serviced in a timely manner.

In addition, congestion, and hence prioritization, can occur anywhere in the transport network, which means that a reordering could take place not only on the ingress point, but anywhere in the network along the entire path.

The loss ratio is calculated based on the aggregate frames being transmitted and received. In an uncongested network, the loss ratio would be 0%. With congestion, not all frames may be sent out to the network (that is, higher priority traffic, and so on) or any one of the transit nodes or the endpoint node might drop the packet, which would end up with loss.

The above-described behavior for following the QoS path equally applies to both Up and Down MEPs. Loss measurements in both up and down directions for the same MEP can be performed simultaneously.

The counters used for loss measurement in LM and CCM frames are appended as late as possible in the datapath. Appending the counters at the last minute to the LM or CCM frames ensures that a scheduling priority issue or some other queue-delaying event does not delay the OAM frame in a queue. If the counters are updated or generated earlier in the datapath, then the OAM frames could be affected by queuing or scheduling delays, which could cause the frames to be counted as lost frames when the far-end receive timer expires.

The following notes apply to Y.1731 LM tests.

• Single-ended and dual-ended LM tests cannot be enabled on a MEP simultaneously. That is, either a single-ended or a dual-ended LM test can be enabled on a specific MEP at any one time.

• The behavior and the interaction between single- and dual-ended LM tests are described in the following list. Error conditions, such as correct domain level and valid destination address (DA) MAC, are not covered in the list:

  • if dual-ended LM test is disabled:

    • CCM frames are transmitted with LM counters set to 0

    • CCM frames being received are not processed for LM

    • LMM and LMR frames being received are processed

    • single-ended tests can be enabled (not blocked by CLI)

  • if dual-ended LM test is enabled:

    • single-ended tests cannot be enabled (blocked by CLI)

    • LMM and LMR frames being received will be dropped

• Multiple MEPs bound to the same Epipe SAP but belonging to different MEG levels can perform LM tests simultaneously.

• CCM must be enabled before a dual-ended LM test can be enabled.

• When a dual-ended LM test is enabled, the user cannot disable CCM. The dual-ended LM test needs to be disabled before the CCM can be disabled.

• For dual-ended LM tests, an alarm is declared when frame losses are greater than an alarm threshold configured for the MEP. The granularity of the alarm threshold (declaring or clearing) is 0.01%. The default threshold is set to 0.25%.

• On a per-SAP or per-network interface basis, there is one set of Rx and Tx Local LM counters and one set of Rx and Tx Remote LM counters. LM counters are not separated on a per-MAC source address (SA) basis. All MEPs, regardless of their MD or MEG level, share the same set of Rx and Tx LM counters.

• On the CLI, there are interval counters and accumulated counters. The CCM counters are referred to as Local and FarEnd counters and the accumulated counters are referred to as Near-End and Far-End counters.

• The LM counters are incremented when a user data frame reaches a SAP. Because there is only one set of Tx and Rx Local counters per SAP, each user data frame received by all the MEPs configured on that SAP is counted.

• OAM frames with MEP levels matching or lower than the locally configured MEP level are not counted. They are treated and processed as OAM frames. This functionality applies to both received and transmitted OAM frames. CFM OAM frames at higher MEP levels are counted as user data frames.

  • For example, assume a SAP with two MEPs configured on it; one MEP at level 5 and the other at level 6.

  • When a level 6 OAM frame is received, it is extracted to the CSM for processing and is not counted by LM counters. It is treated as an OAM frame.

  • The same behavior applies in the transmit direction. In the above example, any level 5 or level 6 OAM frames generated by the local SAR would not be counted by the far-end LM counters.

• For dual-ended LM tests, any received CCMs with all LM counters being 0s (zeros) are treated as invalid. In this case, the 7705 SAR resets the LM counters for the current and previous CCMs to 0s (zeros). Accumulated counters are not reset.

• Except for a valid counter rollover scenario, if the value of any CCM/LMR counter is less than the value of the same counter in the previous CCM/LMR frame, then the accumulated values of all counters are not increased; they are kept at the same values as before the last CCM/LMR frame is processed.

• When the first valid CCM/LMR frame — that is, a frame with at least one non-zero LM counter — is received after a dual-ended loss test is enabled or a single-ended loss test is launched, the accumulated values cannot be calculated. In this case, the counters are resaved as current counters. When the next received CCM/LMR frame with valid LM counts is received, it will trigger the update of accumulated counts.

  Accumulated counts always start at 0 for each launch of a single-ended test. However, the accumulated counts do not change nor do they get reset to all 0s when dual-ended loss tests become disabled. For dual-ended loss tests, accumulated counts can be restarted at 0 by removing the existing LM result of a particular MEP with the CLI command clear>eth-cfm>dual-ended-loss-test>mep mep-id domain md-index association ma-index, or the equivalent SNMP command.

The PDU used for ETH-BN information is called the Bandwidth Notification Message (BNM).

The BNM PDU format consists of the following fields:

• MEG level – carries the MEG level of the client MEP (0 to 7); this field can be any value

• Version – current version is 0

• OpCode – value for this PDU type is GMN (32)

• Flags – contains one information element:

  • period – bits 3 to 1 indicate how often BN messages are transmitted; currently, the only valid values are 100 (1 frame/s), 101 (1 frame/10 s), and 110 (1 frame/min)

• TLV Offset – set to 13

• Sub-OpCode – value for this PDU type is BNM (1)

• Nominal Bandwidth – the nominal full bandwidth of the link, in Mb/s; this information is ignored by the 7705 SAR

• Current Bandwidth – the current bandwidth of the link, in Mb/s

• Port ID – a non-zero unique identifier for the port associated with the ETH-BN information, or zero if not used; this information is ignored by the 7705 SAR

• End TLV – all zeros octet value

Typical behavior for ETH-BN is that if no BNM frames are received within an interval of 3.5 times the BNM transmission period indicated in the last BNM frame received, the MEP signals to the management system that it no longer has any bandwidth information (for example, because the full bandwidth has been restored). For the 7705 SAR implementation, no action is taken if no BNM frame arrives within 3.5 periods.

Upon startup or restart of the system, the configured egress rate is used until a BNM arrives on the port with a new bandwidth request from the ETH-BN server MEP.

Event logs are generated each time the egress bandwidth is changed based on reception of a BNM. If a BNM is received that does not result in a bandwidth change, no event log is generated.

BN messages are transmitted with a source MAC address that cannot be a multicast address or have a value of 0. The destination MAC address can be a Class 1 multicast address (that is, 01-80-C2-00-0x) or the MAC address of the configured port. If these conditions are not satisfied, the message is discarded. The packets are rate-limited to the CSM as are all OAM packets.

BN messages with zero, one, or two VLAN tags are supported.

Some physical layer devices support unidirectional OAM operation. When a link is operating in unidirectional OAM mode, the OAM sublayer ensures that only information OAMPDUs with the Link Fault critical link event indication set and no Information TLVs are sent across the link.

EFM OAM provides a link-layer frame loopback mode, which can be controlled remotely.

To initiate a remote loopback, the local EFM OAM client enables the OAM remote loopback command to send a loopback control OAMPDU. After receiving the loopback control OAMPDU, the remote OAM client puts the remote port into local loopback mode.

OAMPDUs are slow protocol frames that contain appropriate control and status information used to monitor, test, and troubleshoot OAM-enabled links.

To exit a remote loopback, the local EFM OAM client sends a loopback control OAMPDU by disabling the OAM remote loopback command. After receiving the loopback control OAMPDU, the remote OAM client puts the port back into normal forwarding mode.

When a port is in local loopback mode (the far end requested an Ethernet OAM loopback), any packets received on the port will be looped back, except for EFM OAMPDUs. No data will be transmitted from the node; only data that is received on the node will be sent back out.

When the node is in remote loopback mode, local data from the CSM is transmitted, but any data received on the node is dropped, except for EFM OAMPDUs.

Remote loopbacks should be used with caution; if dynamic signaling and routing protocols are used, all services go down when a remote loopback is initiated. If only static signaling and routing is used, the services stay up. On the 7705 SAR, the Ethernet port can be configured to accept or reject the remote-loopback command.

Customers who subscribe to Epipe service might have customer equipment running 802.3ah at both ends. The 7705 SAR can be configured to tunnel EFM OAMPDUs received from a customer device to the other end through the existing network using MPLS or GRE, or to terminate received OAMPDUs at a network or an access Ethernet port.

While tunneling offers the ability to terminate and process the OAM messages at the head-end, termination on the first access port at the cell site can be used to detect immediate failures or can be used to detect port failures in a timelier manner.

The user can choose either tunneling or termination, but not both at the same time.

In EFM OAM (Dot3ah) Capabilities on the 7705 SAR, scenario 1 shows the termination of received EFM OAMPDUs from a customer device on an access port, while scenario 2 shows the same thing except for a network port. Scenario 3 shows tunneling of EFM OAMPDUs through the associated Ethernet PW. To configure termination (scenario 1), use the config>port>ethernet>efm-oam>no shutdown command.

Dying gasp is used to notify the far end that EFM-OAM is disabled or shut down on the local port. The dying gasp flag is set on the OAMPDUs that are sent to the peer. The far end can then take immediate action and inform upper layers that EFM-OAM is down on the port.

When a dying gasp is received from a peer, the node logs the event and generates an SNMP trap to notify the operator.

Typically, an Ethernet port loopback only echoes back received frames. That is, the received source and destination MAC addresses are not swapped. However, not all Ethernet equipment supports echo mode, where the original sender of the frame must support receiving its own port MAC address as the destination MAC address.

The MAC swapping feature on the 7705 SAR is an optional feature that swaps the received destination MAC address with the source MAC address when an Ethernet port is in loopback mode. After the swap, the FCS is recalculated to ensure the validity of the Ethernet frame and to ensure that the frame is not dropped by the original sender because of a CRC error.

EFM OAM and line loopback are mutually exclusive. If one of these functions is enabled, it must be disabled before the other can be used.

However, a line loopback precedes the dot1x behavior. That is, if the port is already dot1x-authenticated it will remain so. If it is not, EAP authentication will fail.

Ethernet port-layer line loopback and Ethernet port-layer internal loopback can be enabled on the same port with the down-when-looped feature. EFM OAM cannot be enabled on the same port with the down-when-looped feature. For more information,see the 7705 SAR Interface Configuration Guide, "Ethernet Port Down-When-Looped".

The trace query must be sent to the multicast router that is the last hop on the path from the source to the receiver. If the receiver is on the local subnet (as determined by the subnet mask), then the default method is to send the trace query to all-routers.mcast.net (224.0.0.2) with a TTL of 1. Otherwise, the trace query is sent to the group address since the last-hop router will be a member of that group if the receiver is. Therefore, it is necessary to specify a group that the intended receiver has joined. This multicast query is sent with a default TTL of 64, which may not be sufficient for all cases.

When tracing from a multihomed host or router, the default receiver address may not be the required interface for the path from the source. In that case, the required interface should be specified explicitly as the receiver.

By default, mtrace first attempts to trace the full reverse path, unless the number of hops to trace is explicitly set with the hop option. If there is no response within a 3-s timeout interval, a "*" is displayed and the probing switches to hop-by-hop mode. Trace queries are issued starting with a maximum hop count of one and increasing by one until the full path is traced or no response is received. At each hop, multiple probes are sent. The first attempt is made with the unicast address of the host running mtrace as the destination for the response. Because the unicast route may be blocked, the remainder of attempts request that the response be sent to mtrace.mcast.net (224.0.1.32) with the TTL set to 32 more than what is needed to pass the thresholds seen so far along the path to the receiver. For the last attempts, the TTL is increased by another 32.

Alternatively, the TTL may be set explicitly with the TTL option.

For each attempt, if no response is received within the timeout, a "*" is displayed. After the specified number of attempts have failed, mtrace will try to query the next-hop router with a DVMRP_ASK_NEIGHBORS2 request (as used by the mrinfo feature) to determine the router type.

The output of mtrace is a short listing of the hops in the order they are queried, that is, in the reverse of the order from the source to the receiver. For each hop, a line is displayed showing:

• the hop number (counted negatively to indicate that this is the reverse path)

• the multicast routing protocol

• the threshold required to forward data (to the previous hop in the listing as indicated by the up-arrow character)

• the cumulative delay for the query to reach that hop (valid only if the clocks are synchronized)

The response ends with a line showing the round-trip time which measures the interval from when the query is issued until the response is received, both derived from the local system clock.

Mtrace/mstat packets use special IGMP packets with IGMP type codes of 0x1E and 0x1F.

global
    - oam
        - atm-ping {port-id | bundle-id [:vpi | vpi/vci]} [end-to-end | segment] [dest destination-id] [send-count send-count] [timeout timeout] [interval interval]

For descriptions of Router TWAMP Light commands, see the Router Configuration Guide.

config
    - router
        - twamp-light
            - [no] reflector
                - description description-string
                - [no] prefix ip-prefix/prefix-length [create]
                    - description description-string
                - udp-port number
                - no udp-port 
                - [no] shutdown

For descriptions of VPRN TWAMP Light commands, see the Services Guide.

config
    - service
        - vprn
            - twamp-light 
                - [no] reflector
                    - description description-string
                    - [no] prefix ip-prefix/prefix-length [create]
                        - description description-string
                    - udp-port number
                    - no udp-port 
                    - [no] shutdown

config
    - test-oam
        - twamp 
            - twamp-light 
                - inactivity-timeout seconds
                - no inactivity-timeout 

config
    - test-oam
        - mpls-echo-request-downstream-map {dsmap | ddmap}

global
    - oam
        - lsp-ping lsp-name [path path-name] 
        - lsp-ping bgp-label prefix ip-prefix/prefix-length [path-destination ip-address [interface if-name | next-hop ip-address]] 
        - lsp-ping prefix ip-prefix/prefix-length [path-destination ip-address [interface if-name | next-hop ip-address]]
        - lsp-ping sr-isis prefix ip-prefix/prefix-length [igp-instance igp-instance] [path-destination ip-address [interface if-name | next-hop ip-address]]
        - lsp-ping sr-ospf prefix ip-prefix/prefix-length [igp-instance igp-instance] [path-destination ip-address [interface if-name | next-hop ip-address]]
        - lsp-ping sr-te lsp-name [path path-name] [path-destination ip-address [interface if-name | next-hop ip-address]]
            - NOTE: options common to all lsp-ping cases:
[fc fc-name [profile {in | out}]] [interval interval] [send-count send-count] [size octets] [src-ip-address ip-address] [timeout timeout] [ttl label-ttl] 
        - lsp-trace lsp-name [path path-name] 
        - lsp-trace bgp-label prefix ip-prefix/prefix-length [path-destination ip-address [interface if-name | next-hop ip-address]] 
        - lsp-trace prefix ip-prefix/prefix-length [path-destination ip-address [interface if-name | next-hop ip-address]]
        - lsp-trace sr-isis prefix ip-prefix/prefix-length [igp-instance igp-instance] [path-destination ip-address [interface if-name | next-hop ip-address]]
        - lsp-trace sr-ospf prefix ip-prefix/prefix-length [igp-instance igp-instance] [path-destination ip-address [interface if-name | next-hop ip-address]]
        - lsp-trace sr-te lsp-name [path path-name] ] [path-destination ip-address [interface if-name | next-hop ip-address]]
            - NOTE: options common to all lsp-trace cases: 
[downstream-map-tlv downstream-map-tlv] [fc fc-name [profile {in | out}]] [interval interval] [max-fail no-response-count] [max-ttl max-label-ttl] [min-ttl min-label-ttl] [probe-count probes-per-hop] [size octets] [src-ip-address ip-address] [timeout timeout] 
        - p2mp-lsp-ping {ldp p2mp-identifier [sender-addr ip-address] [leaf-addr ip-address[...up to 5 max]]} [fc fc-name [profile {in | out}]] [size octets] [timeout timeout] [detail]

global
    - oam
        - ldp-treetrace prefix ip-prefix/mask [max-ttl max-label-ttl] [max-path max-paths] [timeout timeout] [retry-count retry-count] [fc fc-name [profile {in | out}]] [downstream-map-tlv {dsmap | ddmap}]

config
    - test-oam
        - [no] ldp-treetrace
            - fc fc-name [profile {in | out}]
            - no fc
            - path-discovery
                - interval minutes
                - no interval
                - max-path max-paths
                - no max-path
                - max-ttl ttl-value
                - no max-ttl
                - policy-statement policy-name [policy-name...(up to 5 max)]
                - no policy-statement
                - retry-count retry-count
                - no retry-count
                - timeout timeout
                - no timeout
            - path-probing
                - interval minutes
                - no interval 
                - retry-count retry-count
                - no retry-count 
                - timeout timeout
                - no timeout 
            - [no] shutdown

global
    - oam
        - sdp-mtu orig-sdp-id size-inc start-octets end-octets [step step-size] [timeout timeout] [interval interval]
        - sdp-ping orig-sdp-id [resp-sdp resp-sdp-id] [fc fc-name [profile {in | out}]] [size octets] [count send-count] [timeout timeout] [interval interval] 

global
    - oam
        - svc-ping ip-address service [service-id] [local-sdp] [remote-sdp]
        - vprn-ping [service-id | service service-name] source ip-address destination ip-address [fc fc-name [profile {in | out}]] [size size] [ttl vc-label-ttl] [count send-count] [return-control] [timeout timeout] [interval interval]
        - vprn-trace [service-id | service service-name] source ip-address destination ip-address [fc fc-name [profile {in | out}]] [size size] [min-ttl vc-label-ttl] [max-ttl vc-label-ttl] [probe-count send-count] [return-control] [timeout timeout] [interval interval] 

global
    - oam
        - vccv-ping sdp-id:vc-id [src-ip-address ip-addr dst-ip-address ip-addr pw-id pw-id] [reply-mode {ip-routed | control-channel}] [fc fc-name [profile {in | out}]] [size octets] [count send-count] [timeout timeout] [interval interval] [ttl vc-label-ttl]
        - vccv-trace sdp-id:vc-id [size octets] [min-ttl min-vc-label-ttl] [max-ttl max-vc-label-ttl] [max-fail no-response-count] [probe-count probe-count] [reply-mode {ip-routed | control-channel}] [timeout timeout-value] [interval interval-value] [fc fc-name [profile {in | out}]] [detail]

global
    - oam
        - testhead test-name [owner test-owner] testhead-profile profile-id [frame-payload frame-payload-id] sap sap-id [acceptance-criteria acceptance-criteria-id] [color-aware {enable | disable}] [performance-monitoring {enable | disable}]
        - testhead test-name owner test-owner stop
config
    - test-oam
        - testhead-marker-packet-src-mac mac-address
        - testhead-profile profile-id [create]
            - acceptance-criteria acceptance-criteria-id [create]
            - no acceptance-criteria acceptance-criteria-id 
                - cir-threshold cir-threshold
                - no cir-threshold 
                - jitter-rising-threshold threshold
                - no jitter-rising-threshold 
                - jitter-rising-threshold-in in-profile-threshold
                - no jitter-rising-threshold-in 
                - jitter-rising-threshold-out out-profile-threshold
                - no jitter-rising-threshold-out 
                - latency-rising-threshold threshold
                - no latency-rising-threshold 
                - latency-rising-threshold-in in-profile-threshold
                - no latency-rising-threshold-in 
                - latency-rising-threshold-out out-profile-threshold
                - no latency-rising-threshold-out 
                - loss-rising-threshold threshold
                - no loss-rising-threshold 
                - loss-rising-threshold-in in-profile-threshold
                - no loss-rising-threshold-in 
                - loss-rising-threshold-out out-profile-threshold
                - no loss-rising-threshold-out 
                - pir-threshold pir-threshold
                - no pir-threshold 
            - description description-string
            - no description 
            - frame-payload payload-id [payload-type [l2 | tcp-ipv4 | udp-ipv4 | ipv4]] [create]
            - no frame-payload payload-id
                - data-pattern hex-string
                - no data-pattern 
                - description description-string
                - no description 
                - [no] dscp dscp-name
                - dst-ip ipv4 ipv4-address
                - no dst-ip ipv4 
                - dst-mac ieee-address
                - no dst-mac
                - dst-port dst-port-number
                - no dst-port 
                - ethertype 0x0600..0xffff
                - no ethertype 
                - frame-size frame-size
                - no frame-size 
                - ip-proto ip-protocol-number
                - no ip-proto 
                - ip-tos type-of-service
                - no ip-tos 
                - ip-ttl ttl-value
                - no ip-ttl 
                - rate rate-in-kbs
                - no rate 
                - src-ip ipv4 ipv4-address
                - no src-ip 
                - src-mac ieee-address
                - no src-mac
                - src-port src-port-number
                - no src-port 
                - vlan-tag-1 vlan-id vlan-id [tpid tpid] [dot1p dot1p-value]
                - no vlan-tag-1
                - vlan-tag-2 vlan-id vlan-id [tpid tpid] [dot1p dot1p-value]
                - no vlan-tag-2
            - rate cir cir-rate-in-kbs [pir pir-rate-in-kbs]
            - no rate
            - [no] test-completion-trap-enable
            - test-duration {[hours hours] [minutes minutes] [seconds seconds]}
            - no test-duration

    - config
        - service
            - [no] epipe service-id [customer customer-id] [vpn vpn-id] [vc-switching]
                - sap sap-id [no-endpoint]
                    - loopback {line | internal} {timer seconds | persistent} [swap-src-dst-mac]
                    - no loopback

global
    - oam
        - cpe-ping service service-id destination ip-address [source ip-address] [source-mac ieee-address] [fc fc-name [profile [in | out]] [ttl vc-label-ttl] [count send-count] [send-control] [return-control] [timeout timeout] [interval interval] 
        - mac-ping service service-id destination dst-ieee-address [source src-ieee-address] [fc fc-name [profile {in | out}]] [ttl vc-label-ttl] [count send-count] [send-control] [return-control] [interval interval] [timeout timeout] 
        - mac-populate service-id mac ieee-address [flood] [age seconds] [force] [target-sap sap-id] [send-control] 
        - mac-purge service-id target ieee-address [flood] [send-control] [register] [force]
        - mac-trace service service-id destination ieee-address [source ieee-address] [fc fc-name [profile {in | out}]] [size octets] [min-ttl vc-label-ttl] [max-ttl vc-label-ttl] [probe-count send-count] [send-control] [return-control] [interval interval] [timeout timeout] 

global
    - oam
        - efm port-id
            - local-loopback {start | stop}
            - remote-loopback {start | stop}
config
    - [no] port {port-id}
        - ethernet
            - efm-oam
                - [no] accept-remote-loopback
                - hold-time time-value
                - no hold-time
                - mode {active | passive}
                - [no] shutdown
                - [no] transmit-interval interval [multiplier multiplier]
                - [no] tunneling

global
    - oam
        - eth-cfm
            - eth-test mac-address mep mep-id domain md-index association ma-index [priority priority] [data-length data-length] 
            - linktrace mac-address mep mep-id domain md-index association ma-index [ttl ttl-value]
            - loopback mac-address mep mep-id domain md-index association ma-index [send-count send-count] [size data-size] [priority priority]
            - one-way-delay-test mac-address mep mep-id domain md-index association ma-index [priority priority] 
            - single-ended-loss-test mac-address mep mep-id domain md-index association ma-index [priority priority] [interval {100ms | 1s}] [send-count send-count]
            - two-way-delay-test mac-address mep mep-id domain md-index association ma-index [priority priority] 
            - two-way-slm-test mac-address mep mep-id domain md-index association ma-index [priority priority] [send-count send-count] [size data-size] [timeout timeout] [interval interval]
config
    - eth-cfm 
        - domain md-index [format {dns | mac | none | string}] name md-name level level
        - domain md-index
        - no domain md-index
            - association ma-index [format {icc-based | integer | string | vid | vpn-id}] name ma-name
            - association ma-index
            - no association ma-index
                - [no] bridge-identifier bridge-id
                    - vlan vlan-id
                    - no vlan
                - ccm-interval {10ms | 100ms | 1 | 10 | 60 | 600}
                - no ccm-interval 
            - [no] remote-mepid mep-id
        - slm 
            - inactivity-timer timeout
            - no inactivity-timer
config
    - [no] port {port-id}
        - ethernet
            - cfm-loopback priority {low | high | dot1p} [match-vlan {vlan-range | none}]
            - no cfm-loopback 
config
    - service
        - epipe service-id [customer customer-id] [create] [vpn vpn-id]
            - sap sap-id [create]
                - eth-cfm
                    - [no] hold-mep-up-on-failure 
                    - mep mep-id domain md-index association ma-index [direction {up | down}]
                    - no mep mep-id domain md-index association ma-index
                        - [no] ais-enable
                            - client-meg-level [level [level ...]]
                            - no client-meg-level
                            - interval [1 | 60]
                            - no interval
                            - priority priority-value
                            - no priority
                        - [no] ccm-enable
                        - ccm-ltm-priority priority
                        - no ccm-ltm-priority
                        - description description-string
                        - no description
                        - [no] dual-ended-loss-test-enable
                            - alarm-clear-threshold percentage
                            - no alarm-clear-threshold
                            - alarm-threshold percentage
                            - no alarm-threshold
                        - [no] eth-test-enable
                            - bit-error-threshold bit-errors
                            - test-pattern {all-zeros | all-ones} [crc-enable]
                            - no test-pattern
                        - low-priority-defect {allDef | macRemErrXcon | remErrXcon | errXcon | xcon | noXcon}
                        - one-way-delay-threshold seconds
                        - [no] shutdown
            - spoke-sdp sdp-id:vc-id [vc-type {ether | vlan}] [create] [no-endpoint]
            - spoke-sdp sdp-id:vc-id [vc-type {ether | vlan}] [create] endpoint endpoint-name
                - eth-cfm
                    - mep mep-id domain md-index association ma-index [direction {up | down}]
                    - no mep mep-id domain md-index association ma-index
                        - [no] ccm-enable
                        - ccm-ltm-priority priority
                        - no ccm-ltm-priority
                        - description description-string
                        - no description
                        - low-priority-defect {allDef | macRemErrXcon | remErrXcon | errXcon | xcon | noXcon}
                        - [no] shutdown
config
    - service
        - vpls service-id [customer customer-id] [create]
            - sap sap-id [create]
                - eth-cfm
                    - mep mep-id domain md-index association ma-index [direction {up | down}]
                    - no mep mep-id domain md-index association ma-index
                        - [no] ais-enable
                            - client-meg-level [level [level ...]]
                            - no client-meg-level
                            - interval [1 | 60]
                            - no interval
                            - priority priority-value
                            - no priority
                        - [no] ccm-enable
                        - ccm-ltm-priority priority
                        - no ccm-ltm-priority
                        - description description-string
                        - no description
                        - [no] eth-test-enable
                            - bit-error-threshold bit-errors
                            - test-pattern {all-zeros | all-ones} [crc-enable]
                            - no test-pattern 
                        - low-priority-defect {allDef | macRemErrXcon | remErrXcon | errXcon | xcon | noXcon}
                        - mac-address mac-address
                        - no mac-address
                        - one-way-delay-threshold seconds
                        - [no] shutdown
            - mesh-sdp sdp-id[:vc-id] [vc-type {ether | vlan}] [create]
                - eth-cfm
                    - mep mep-id domain md-index association ma-index [direction {up | down}]
                    - no mep mep-id domain md-index association ma-index
                        - [no] ccm-enable
                        - ccm-ltm-priority priority
                        - no ccm-ltm-priority
                        - description description-string
                        - no description
                        - low-priority-defect {allDef | macRemErrXcon | remErrXcon | errXcon | xcon | noXcon}
                        - [no] shutdown
            - spoke-sdp sdp-id:vc-id [vc-type {ether | vlan}] [split-horizon-group group-name] [create] [no-endpoint]
            - spoke-sdp sdp-id:vc-id [vc-type {ether | vlan}] [split-horizon-group group-name] [create] endpoint endpoint-name
                - eth-cfm
                    - mep mep-id domain md-index association ma-index [direction {up | down}]
                    - no mep mep-id domain md-index association ma-index
                        - [no] ccm-enable
                        - ccm-ltm-priority priority
                        - no ccm-ltm-priority
                        - description description-string
                        - no description
                        - low-priority-defect {allDef | macRemErrXcon | remErrXcon | errXcon | xcon | noXcon}
                        - [no] shutdown
config
    - router [router-name]
        - interface ip-int-name
            - eth-cfm
                - mep mep-id domain md-index association ma-index
                - no mep mep-id domain md-index association ma-index
                    - [no] ccm-enable
                    - ccm-ltm-priority priority
                    - no ccm-ltm-priority
                    - ccm-tlv-ignore [port-status] [interface-status]
                    - no ccm-tlv-ignore 
                    - description description-string
                    - no description
                    - [no] dual-ended-loss-test-enable
                        - alarm-threshold percentage
                        - no alarm-threshold
                        - alarm-clear-threshold percentage
                        - no alarm-clear-threshold
                    - [no] eth-test-enable
                        - bit-error-threshold bit-errors
                        - [no] test-pattern {all-zeros | all-ones} [crc-enable]
                    - low-priority-defect {allDef | macRemErrXcon | remErrXcon | errXcon | xcon | noXcon}
                    - one-way-delay-threshold seconds
                    - [no] shutdown

global
    - oam
        - saa test-name [owner test-owner] {start | stop}