3.1.1.1. Ping

Ping is used to determine if there is IP layer connectivity between the 7705 SAR and another node in the network.

The 7705 SAR supports redirection of SGT to egress data queues rather than the default control queue. To redirect ping to a data queue, the ping command includes the fc-queue option, which specifies the queue to be used for servicing the ping packets in the egress direction. All other SGT applications are redirected using the config>router>sgt-qos>application>fc-queue or config>service>vprn>sgt-qos>application>fc-queue command. For more information on SGT redirection, refer to the 7705 SAR Quality of Service Guide, “SGT Redirection”.

3.1.1.2. Traceroute

Traceroute is used to determine the path that an IP packet takes from the 7705 SAR to a specified router.

3.1.2.1. 7705 SAR Support for TWAMP Server

The 7705 SAR supports the TWAMP server and the session reflector functions, as shown in Figure 3.

Figure 3:  7705 SAR as TWAMP Server and Session Reflector 

The 7705 SAR plays a passive role: the TWAMP control client initiates the control session with the 7705 SAR in order to negotiate the following:

The 7705 SAR responds, and when the negotiation is complete, the 7705 SAR performs the following:

TWAMP is supported on all IPv4 interfaces and on the base router of any interface address, including the system and loopback IP addresses. Any IP address can be used to terminate TWAMP control and test packets.

Datapath timestamping in both ingress and egress directions for TWAMP frames is supported on all datapath Ethernet ports on the following adapter cards, modules, and standalone nodes:

Note: A 7705 SAR node using GNSS or IEEE 1588v2 PTP for time of day/phase recovery can perform high-accuracy timestamping for TWAMP packets. Refer to the 7705 SAR Basic System Configuration Guide for information about node timing sources.

CSM-based egress timestamping for TWAMP is supported on:

For information about how to configure the TWAMP server and the TWAMP command hierarchy, see the OAM commands for TWAMP.

The 7705 SAR supports a show>test-oam>twamp>server command that displays information about the TWAMP server configuration and statistics, and the clients associated with each server address prefix. See the Show Commands for more information. The 7705 SAR also supports a dump command that displays statistics for dropped connections, dropped connection states, rejected sessions, and dropped test packets. See Dump Test-OAM Commands for more information.

3.1.2.2. Two-Way Active Measurement Protocol Light (TWAMP Light)

TWAMP Light is an optional model included in the TWAMP standard RFC 5357, A Two-Way Active Measurement Protocol (TWAMP). TWAMP Light uses the standard TWAMP packet format but provides a simpler approach to gathering ongoing IP delay and synthetic loss performance data for the base router and per-VPRN statistics. Full details are described in Appendix I of RFC 5357.

With TWAMP Light, the TWAMP client/server model is replaced with a session controller/responder model. The server, control-client and session-sender role is combined in one host called the controller, and the session-reflector role is in another host called the responder. In general terms, the session controller is the launch point for the TWAMP test packets and the responder reflects the packets.

TWAMP Light maintains the TWAMP test packet exchange but eliminates the TWAMP TCP control connection with local configurations; however, not all negotiated control parameters are replaced with local configurations. The DSCP value in an incoming TWAMP test packet is reflected back to the originator. The incoming TWAMP test packet is classified to a specific FC based on the ingress QoS policy and the dot1p in the reflected packet is determined by the FC to dot1p mapping in the egress QoS policy.

The reflector function is configured under the config>router>twamp-light command hierarchy for base router reflection, and under the config>service>vprn>twamp-light command hierarchy for per-VPRN reflection. The TWAMP Light reflector function is configured per context and must be activated before reflection can occur; the function is not enabled by default for any context. The reflector requires the operator to define the TWAMP Light UDP listening port that identifies the TWAMP Light protocol and to define the prefixes that the reflector will accept as valid sources for a TWAMP Light request.

If the source IP address in the TWAMP Light packet arriving on the responder does not match a configured IP address prefix, the packet is dropped. Multiple prefix entries may be configured per context on the responder. Configured prefixes can be modified without shutting down the reflector function. An inactivity timeout under the config>oam-test>twamp>twamp-light command hierarchy defines the amount of time the reflector will keep the individual reflector sessions active in the absence of test packets.

TWAMP uses a single packet to gather both delay and loss metrics. This means there is special consideration over those approaches that utilize a specific tool per metric type.

TWAMP Light is supported for deployments that use IPv4 or IPv6 addressing, which may each have their own hardware requirements. All IP addressing must be unicast. IPv6 addresses cannot be reserved or link local addresses. Multiple test sessions may be configured between the same source and destination IP endpoints. The 4-tuple lookup (source IP, destination IP, source UDP, destination UDP provides a unique index for each test point.

Note: A 7705 SAR node using GNSS or IEEE 1588v2 PTP for time of day/phase recovery can perform high-accuracy timestamping for TWAMP Light packets.

3.1.3.1. LSP Ping

LSP ping, as described in RFC 4379, provides a mechanism to detect data plane failures in MPLS LSPs. For a given FEC, LSP ping verifies whether the packet reaches the egress label edge router (eLER).

A 7705 SAR node using GNSS or IEEE 1588v2 PTP for time of day/phase recovery can perform LSP ping tests with high-accuracy timestamping. Refer to the 7705 SAR Basic System Configuration Guide, “Node Timing”, for information about node timing sources.

3.1.3.2. LSP Traceroute

LSP traceroute sends a packet to each transit LSR along a communications path until the far-end router is reached. The path is traced one LSR at a time, where each LSR that receives a traceroute packet replies to the initiating 7705 SAR with a packet that identifies itself. Once the final LSR is identified, the initiating LSR has a list of all LSRs on the path. Like IP traceroute, LSP traceroute is a hop-by-hop operation (that is, LSR by LSR).

Use LSP traceroute to determine the exact litigation of LSP failures.

3.1.3.3. LSP Ping and LSP Traceroute for BGP Route Tunnels

LSP ping and LSP traceroute are supported on BGP route tunnels using existing LSP ping and traceroute commands with the bgp-label prefix option. The system uses the DSMAP TLV target FEC stack TLV for BGP-labeled IPv4 /32 prefix as defined in RFC 4379, Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures. Figure 4 shows the new TLV structure.

Figure 4:  Target FEC Stack TLV for BGP-Labeled IPv4 Prefix 

The following process is used when sending or responding to an LSP ping or LSP traceroute packet on BGP route tunnels.

Note: The 7705 SAR supports only BGP-labeled IPv4 /32 prefixes in LSP ping and LSP trace.

For more information on BGP route tunnels, refer to the 7705 SAR Routing Protocols Guide, “BGP Route Tunnels”.

3.1.3.4. Downstream Detailed Mapping (DDMAP) TLV

The DDMAP TLV, as defined in RFC 6424, provides users with the same features as the existing DSMAP TLV along with enhancements that allow LSP diagnostics to trace the details of LSP hierarchy. With the DDMAP TLV, all intermediate routers will appear in the LSP ping and traceroute lists, and intermediate nodes can append additional data with details about their relative functionality. The DDMAP TLV format is derived from the DSMAP TLV format with variable length and optional fields converted into sub-TLVs. Figure 5 shows the DDMAP TLV format.

Figure 5:  DDMAP TLV 

The following process is used when sending or responding to an LSP ping or LSP traceroute packet using the DSMAP or DDMAP TLV.

The user can globally configure the downstream mapping TLV to be used for all LSP trace and LDP treetrace packets with the configure test-oam mpls-echo-request-downstream-map command. The configured global value becomes the default downstream mapping TLV for all newly created LSP trace and LDP treetrace tests. It has no effect on existing tests and can be overridden on a specific test by setting the downstream-map-tlv parameter in the lsp-trace or ldp-treetrace context.

3.1.3.4.1. Using The DDMAP TLV in LSP Stitching and LSP Hierarchy

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

Note: The 7705 SAR does not support LSP stitching.

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 Figure 6. The field definitions match those of the DSMAP TLV and are described in RFC 4379.

Figure 6:  FEC Stack Change Sub-TLV 

The operation type specifies the action associated with the FEC stack change. Table 2 defines the operation types for the FEC stack change sub-TLV.

Table 2:  FEC Stack Change Sub-TLV Operation Types 

Type #	Operation
1	Push
2	Pop

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.

Figure 7 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.

Figure 7:  BGP 3107 Tunnel Through 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  224.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 

3.1.4.1. SDP Ping

SDP ping performs in-band unidirectional or round-trip connectivity tests on SDPs. The SDP ping OAM packets are sent in-band, in the tunnel encapsulation, so it will follow the same path as traffic within the service. The SDP ping response can be received out-of-band in the control plane, or in-band using the data plane for a round-trip test.

For a unidirectional test, SDP ping tests:

For a round-trip test, SDP ping uses a local egress SDP ID and an expected remote SDP ID. Since SDPs are unidirectional tunnels, the remote SDP ID must be specified and must exist as a configured SDP ID on the far-end 7705 SAR.

SDP round-trip testing is an extension of SDP connectivity testing with the additional ability to test:

3.1.4.2. SDP MTU Path Discovery

In a large network, network devices can support a variety of packet sizes that are transmitted across their interfaces. The largest packet (including headers) can be as large as the Maximum Transmission Unit (MTU). An MTU specifies the largest packet size, measured in octets, that can be transmitted through a network entity. It is important to understand the MTU of the entire path (end-to-end) when provisioning services, especially for VLL services where the service must support the ability to transmit the extra large customer packets.

The Path MTU Discovery tool is a powerful tool that enables service providers to get the exact MTU supported between the service ingress and service termination points, accurate to 1 byte.

Note: The sdp-mtu command probes the far-end port using the configured MTU of the near-end port, not the configured MTU of the far-end port. For example, a far-end port that is physically capable of receiving jumbo frames would respond to sdp-mtu probes up to the jumbo frame size, regardless of the configured MTU of the far-end port. This assumes that the intermediate transport network can switch frames of this size.

3.1.5.1. Service Ping

Service (SVC) ping is initiated from a 7705 SAR router to verify round-trip connectivity and delay to the far end of the service. Service ping applies to GRE, IP, and MPLS tunnels and tests the following from edge-to-edge:

3.1.6.1. VCCV Ping

VCCV ping is used to check the connectivity (in-band) of a VLL. It checks that the destination (target) PE is the egress point for the Layer 2 FEC. It provides a cross-check between the data plane and the control plane. It is in-band, meaning that the VCCV ping message is sent using the same encapsulation and along the same path as user packets in that VLL. This is equivalent to the LSP ping for a VLL service. VCCV ping reuses an LSP ping message format and can be used to test a VLL configured over an MPLS, GRE, or IP SDP.

A 7705 SAR node using GNSS or IEEE 1588v2 PTP for time of day/phase recovery can perform VCCV ping tests with high-accuracy timestamping. Refer to the 7705 SAR Basic System Configuration Guide, “Node Timing”, for information about node timing sources.

3.1.6.1.1. VCCV Ping Application

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

Figure 8:  VCCV Ping Application 

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:

1. Type 1 — in-band VCCV (special control word)
   Type 1 uses the OAM control word, which is shown in Figure 9.

   Figure 9:  OAM Control Word Format 

   
   In Figure 9, 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.
2. 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.
3. 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 Figure 10.

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

Figure 10:  VCCV TLV 

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

1. 0x00 — none of the following VCCV control channel types (Type 1, Type 2, or Type 3) are supported
2. 0x01 — (Type 1, in-band) PWE3 OAM control word (see Figure 9)
3. 0x02 — (Type 2, out-of-band) MPLS router alert label
4. 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, then 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:

1. 0x00 — none of the following VCCV packet types are supported
2. 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:

1. do not reply
   This mode is supported by the 7705 SAR.
2. reply by an IPv4 UDP packet
   This mode is supported by the 7705 SAR.
3. reply via an IPv4 UDP packet with router alert
   This mode is not supported by the 7705 SAR.

   Note: Do not confuse this mode, which sets the router alert bit in the IP header, with the CC type that makes use of the router alert label.

4. 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.

3.1.6.1.2. VCCV Ping in a Multi-Segment Pseudowire

Figure 11 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.

Figure 11:  VCCV Ping Over a Multi-Segment Pseudowire 

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.

3.1.6.1.5. VCCV for MS-PW and Pseudowire Redundancy

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.

Note: A VLL service is in MS-PW and PW redundancy mode as long as there is one PW segment with an explicit endpoint configured.

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 towards the CSM.

3.1.6.2. VCCV Trace

VCCV trace is similar to LSP trace. VCCV trace is used to trace the entire path of a pseudowire (PW) with a single command.

VCCV trace is useful in multi-segment PW (MS-PW) applications where a single PW traverses one or more switched PEs (S-PEs). VCCV trace is an iterative process by which the initiating terminating PE (T-PE) sends successive VCCV ping messages, each message having an incrementing TTL value, starting from TTL=1. The procedure for each iteration is the same as that for VCCV-ping, where each node in which the VC label TTL expires will check the FEC and reply with the FEC to the downstream S-PE or far-end T-PE. The process is terminated when the reply is from the far-end T-PE or when a timeout occurs.

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

3.1.7.1. ITU-T Y.1564 Functionality

The 7705 SAR supports the test heads, as defined in RFC 2544, for ITU-T Y.1564. Test heads allow users to configure a set of trusted procedures to use during testing.

An ITU-T Y.1564 test head cannot survive activity switches (on platforms supporting HA), or any maintenance operation at the port, SAP, service level. The user must restart the test from the newly active CSM. If an activity switch occurs during an active test, all statistics and measurement data are lost.

An Ethernet SAP loopback can survive a CSM activity switch if it is enabled with the persistent keyword. Otherwise, the loopback is also reset during an activity switch. Ethernet SAP loopbacks are supported on LAG and MC-LAG ports on second-generation and third-generation Ethernet cards.

ITU-T Y.1564 test heads rely on delay and delay variation when calculating jitter. For more details, refer to RFC 3550, section A.8.

Users can configure the following frame type using the frame-payload command: Layer 2 payload, IPv4 payload, and IP/TCP/UDP payload. The test head uses the configured values for the IP header fields and TCP header fields based on the payload type configured.

The test head implementation on the 7705 SAR allows users to run tests with up to four parallel flows by specifying up to four frame payload IDs in the oam>testhead command. This allows users to test a service with IMIX-type traffic patterns.

3.1.7.2. ITU-T Y.1564 Protocol Interaction

CFM OAM must be explicitly disabled in order for an ITU-T Y.1564 test or Ethernet SAP loopback to be operational. You can enable a Y.1564 test head or Ethernet SAP loopback, or enable CFM OAM, but not both simultaneously (see Table 3).

3.1.8.1. MAC Ping

For a MAC ping test, the destination MAC address (unicast or multicast) to be tested must be specified. A MAC ping packet can be sent through the control plane or the data plane. When sent by the control plane, the ping packet goes directly to the destination IP in a UDP/IP OAM packet. When it is sent by the data plane, the ping packet goes out with the data plane format.

In the control plane, a MAC ping is forwarded along the flooding domain if no MAC address bindings exist. If MAC address bindings exist, then the packet is forwarded along those paths (if they are active). Finally, a response is generated only when there is an egress SAP binding to that MAC address. A control plane request is responded to via a control reply only.

In the data plane, a MAC ping is sent with a VC label TTL of 255. This packet traverses each hop using forwarding plane information for next hop, VC label, and so on. The VC label is swapped at each service-aware hop, and the VC TTL is decremented. If the VC TTL is decremented to 0, the packet is passed up to the management plane for processing. If the packet reaches an egress node, and would be forwarded out a customer-facing port, it is identified by the OAM label below the VC label and passed to the management plane.

MAC pings are flooded when they are unknown at an intermediate node. They are responded to only by the egress nodes that have mappings for that MAC address.

A 7705 SAR node using GNSS or IEEE 1588v2 PTP for time of day/phase recovery can perform MAC ping tests with high-accuracy timestamping. Refer to the 7705 SAR Basic System Configuration Guide, “Node Timing”, for information about node timing sources.

3.1.8.2. MAC Trace

A MAC trace operates like an LSP trace with variations. Operations in a MAC trace are triggered when the VC TTL is decremented to 0.

Like a MAC ping, a MAC trace can be sent either by the control plane or the data plane.

When a MAC trace request is sent by the control plane, the destination IP address is determined from the control plane mapping for the destination MAC. If the destination MAC is known to be at a specific remote site, then the far-end IP address of that SDP is used. If the destination MAC is not known, then the packet is sent as a unicast transmission to all SDPs in the service with the appropriate squelching.

A control plane MAC traceroute request is sent via UDP/IP. The destination UDP port is the LSP ping port. The source UDP port is assigned by the system, where the source UDP port is really the demultiplexer that identifies the particular instance that sent the request, when that demultiplexer correlates the reply. The source IP address is the system IP address of the sender.

When a traceroute request is sent via the data plane, the data plane format is used. The reply can be via the data plane or the control plane.

A data plane MAC traceroute request includes the tunnel encapsulation, the VC label, and the OAM, followed by an Ethernet DLC, a UDP, and IP header. If the mapping for the MAC address is known at the sender, then the data plane request is sent down the known SDP with the appropriate tunnel encapsulation and VC label. If it is not known, then it is sent down every SDP (with the appropriate tunnel encapsulation per SDP and appropriate egress VC label per SDP binding).

The tunnel encapsulation TTL is set to 255. The VC label TTL is initially set to the min-ttl (default is 1). The OAM label TTL is set to 2. The destination IP address is the all-routers multicast address. The source IP address is the system IP address of the sender.

The Reply Mode is either 3 (control plane reply) or 4 (data plane reply), depending on the reply-control option. By default, the data plane request is sent with Reply Mode 3 (control plane reply).

The Ethernet DLC header source MAC address is set to either the system MAC address (if no source MAC is specified) or to the specified source MAC. The destination MAC address is set to the specified destination MAC. The Ethertype is set to IP.

3.1.8.3. CPE Ping

The MAC ping OAM tool makes it possible to detect whether a particular MAC address has been learned in a VPLS.

The cpe-ping command extends this capability and can detect end-station IP addresses inside a VPLS. A CPE ping for a specific destination IP address within a VPLS will be translated to a MAC ping towards a broadcast MAC address. Upon receiving such a MAC ping, each peer PE within the VPLS context will trigger an ARP request for the specific IP address. The PE receiving a response to this ARP request will report back to the requesting 7705 SAR. Operators are encouraged to use the source IP address of 0.0.0.0 in order to prevent the provider’s IP address from being learned by the CE.

3.1.8.4. MAC Populate

MAC populate is used to send a message through the flooding domain to learn a MAC address as if a customer packet with that source MAC address had flooded the domain from that ingress point in the service. This allows the provider to craft a learning history and engineer packets in a particular way to test forwarding plane correctness.

The MAC populate request is sent with a VC TTL of 1, which means that it is received at the forwarding plane at the first hop and passed directly up to the management plane. The packet is then responded to by populating the MAC address in the forwarding plane, like a conventional learn, although the MAC will be an OAM-type MAC in the FIB to distinguish it from customer MAC addresses.

This packet is then taken by the control plane and flooded out the flooding domain (squelching appropriately, the sender and other paths that would be squelched in a typical flood).

This controlled population of the FIB is very important to manage the expected results of an OAM test. The same functions are available by sending the OAM packet as a UDP/IP OAM packet. It is then forwarded to each hop and the management plane has to do the flooding.

Options for MAC populate are to force the MAC in the table to type OAM (in case it already existed as dynamic or static or as an OAM-induced learning with some other binding), to prevent new dynamic learning to over-write the existing OAM MAC entry, or to allow customer packets with this MAC to either ingress or egress the network while still using the OAM MAC entry.

Finally, an option to flood the MAC populate request causes each upstream node to learn the MAC, for example, to populate the local FIB with an OAM MAC entry, and to flood the request along the data plane using the flooding domain.

An age can be provided to age a particular OAM MAC after a different interval than other MACs in a FIB.

3.1.8.5. MAC Purge

MAC purge is used to clear the FIBs of any learned information for a particular MAC address. This allows an operator to perform a controlled OAM test without learning induced by customer packets. In addition to clearing the FIB of a particular MAC address, the purge can also indicate to the control plane not to allow further learning from customer packets. This allows the FIB to be clean and be populated only via a MAC populate request.

MAC purge follows the same flooding mechanism as the MAC populate. A UDP/IP version of this command is also available that does not follow the forwarding notion of the flooding domain, but rather the control plane behavior of it.

3.1.9.1. Ethernet OAM Overview

The 7705 SAR supports the following Ethernet OAM capabilities:

Ethernet OAM capabilities on the 7705 SAR are similar to the OAM capabilities offered in SONET/SDH networks and include loopback tests to verify end-to-end connectivity, test pattern generation (and response) to verify error-free operation, and alarm message generation in case of fault conditions to ensure that the far end is notified of the failure.

Ethernet OAM configurations are maintained across Control and Switching module (CSM) switchovers.

3.1.9.1.1. Ethernet OAM Usage Examples

Figure 14 illustrates the complementary use of dot3ah and dot1ag to locate points of failure along a route from BTS to BSC. Since dot1ag and Y.1731 have similar functions, only dot1ag is discussed in order to simplify the explanation.

In Figure 14, 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.

Figure 14:  7705 SAR Ethernet OAM Endpoints 

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 Figure 14, 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). Since 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 Figure 14, 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).

Figure 15 and Figure 16 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 Figure 15, 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.

Figure 15:  ETH-CFM (Dot1ag) Capabilities on the 7705 SAR 

In Figure 16, EFM OAM ensures transport layer connectivity between two directly connected nodes. Figure 16 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:

1. 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
2. scenario 2: EFM termination at the Ethernet network port, which includes network-side loopbacks
3. scenario 3: EFM tunneling through an Epipe service

Figure 16:  EFM OAM (Dot3ah) Capabilities on the 7705 SAR 

3.1.9.2. 802.1ag and Y.1731 Functional Comparison

Table 4 lists the 802.1ag and Y.1731 OAM functions supported on the 7705 SAR. For each function and test, the table identifies the PDU that carries the test data, the test’s target entity, and the standards that the 7705 SAR supports for the test.

For example, the 7705 SAR can run an Ethernet Continuity Check using an ETH-CC test according to the dot1ag and the Y.1731 standards. For either standard, the test data is carried in a Continuity Check message (CCM) and the test target is a MEP.

The Fault Management (FM) capabilities of ITU-T Y.1731 extend the functionality of dot1ag (ETH-CFM) with additional FM functions as well as performance monitoring (PM) capabilities. The generation of AIS and RDI messages are defined under the FM section of the Y.1731 specification, whereas Ethernet layer, delay, jitter, loss, and throughput tests are part of Y.1731 PM capabilities.

3.1.9.3. ETH-CFM Ethernet OAM Tests (802.1ag and Y.1731)

Ethernet Connectivity Fault Management (ETH-CFM) is defined in the IEEE 802.1ag and ITU Y.1731 standards. ETH-CFM specifies protocols, procedures, and managed objects to support fault management (including discovery and verification of the path), detection, and isolation of a connectivity fault in an Ethernet network.

IEEE 802.1ag and Y.1731 can detect:

The implementation of Y.1731 on the 7705 SAR also provides the following enhancements:

ETH-CFM uses Ethernet frames and can be distinguished by its Ethertype value (8902). With ETH-CFM, interoperability can be achieved between different vendor equipment in the service provider network, up to and including customer premises bridges.

ETH-CFM is configured at the global level and at the Ethernet service level and/or network interface level. The following entities and their configuration levels are listed below:

For information on configuring ETH-CFM to set up an Ethernet OAM architecture, refer to the 7705 SAR Services Guide, “ETH-CFM (802.1ag and Y.1731)”. Most of the configuration information applies to Ethernet network interfaces as well; for information on ETH-CFM support specific to network interfaces, refer to the 7705 SAR Router Configuration Guide, “ETH-CFM Support”.

3.1.9.3.2. Loopback (LB)

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 Figure 17, the line labeled LB represents the dot1ag loopback message between the 7750 SR (source) and 7705 SAR (target) over an Epipe. The 7750 SR-generated LBM is switched to the 7705 SAR, where the LBM message is processed. Once the 7705 SAR generates the Loopback Reply message (LBR), the LBR is switched over the Ethernet PW to the 7750 SR.

Figure 17:  Dot1ag Loopback Test 

3.1.9.3.6. ETH-RDI

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 fail and AIS may result in the transmission of frames with ETH-RDI information. ETH-RDI is used only when ETH-CC transmission is enabled.

ETH-RDI has the following two applications:

1. 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.
2. 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:

1. MEG level — the MEG level at which the MEP exists
2. ETH-RDI transmission period — application-dependent and is the same value as the ETH-CC transmission period
3. 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.

Note: When a port or interface experiences a failure, the Up MEP on the port or interface transmits a Port or Interface Status TLV (or both). If the hold-mep-up-on-failure command is enabled: the Up MEP indicates ETH-RDI the remote MEP indicates a DefMACstatus If the hold-mep-up-on-failure command is disabled: the Up MEP indicates a DefRemoteCCM defect the remote MEP indicates both a DefMACstatus and a DefRDICCM defect

3.1.9.3.7. ETH-AIS

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 MEP.

Note: ETH-AIS is not supported on network interface facility MEPs.

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:

1. signal failure conditions in the case where ETH-CC is enabled
2. 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. Once the AIS condition is cleared, a MEP resumes alarm generation upon detecting defect conditions.

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

1. client MEG level — the MEG level at which the most immediate client layer MEPs exist
2. ETH-AIS transmission period — the transmission period of frames with ETH-AIS information
3. priority — the priority of frames with ETH-AIS information

3.1.9.3.8. ETH-Test

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, bit errors, and so on.

Note: The out-of-service diagnostics test is not supported in the 7705 SAR.

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 MEP requires the following configuration information:

1. MEG level — the MEG level at which the MEP exists
2. unicast MAC address — the unicast MAC address of the peer MEP for which the ETH-Test is intended
3. 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.
4. priority — the priority of frames with ETH-Test information

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

3.1.9.4. ITU-T Y.1731 Ethernet Bandwidth Notification (ETH-BN)

The Ethernet Bandwidth Notification (ETH-BN) function, as defined in ITU-T Rec. G.8013/Y.1731, is used by a server MEP to signal changes in link bandwidth to a client MEP.

One of the best applications of this functionality is for point-to-point microwave radios. When a microwave radio uses adaptive modulation, the capacity of the radio can change based on the condition of the microwave link. For example, in adverse weather conditions that cause link degradation, the radio can change its modulation scheme to a more robust one (which will reduce the link bandwidth) in order to continue transmitting. This change in bandwidth is communicated from the server MEP on the radio, using ETH-BNM (Ethernet Bandwidth Notification Message), to the client MEP on the connected router. The router responds to this information by adjusting the rate of traffic being sent to the radio. The server MEP continues to transmit periodic frames with ETH-BN information with the currently available bandwidth. When full bandwidth is restored, the ETH-BNM will start indicating the full bandwidth.

When the 7705 SAR, Release 8.0, is interoperating with 9500 MPR-e radios, ETH-BN functionality is supported with 9500 MPR-e radios in standalone mode. ETH-BN support with MWA mode will be considered in a future release.

The 7705 SAR supports the client side of ETH-BN, receiving and acting on the ETH-BN information sent by the server MEP.

ETH-BN is supported on Ethernet ports on the following adapter cards, modules, and platforms:

The ports can be configured for network, access, or hybrid mode. When ETH-BN is enabled on a port with the egress-rate sub-rate allow-eth-bn-rate-changes command, the egress rate, which was configured as a fixed bandwidth, can be dynamically changed based on the available bandwidth indicated by the ETH-BN server.

The maximum egress rate that the port can be set to is the native port rate (for example, 1 Gb/s), and the minimum egress rate is 1 kb/s. If a rate request is outside that range, including 0, it cannot be implemented, and the egress rate is set as close as possible to the requested rate. The egress rate setting has a ±1% accuracy, as rate conversion to the hardware is necessary. Any request for a change less than 1% is ignored.

To reduce the number of bandwidth changes (each change incurs a small data hit), a hold timer can be configured. The range is 1 to 600 s with a default of 5 s. Any ETH-BN message received before the hold timer expires, after the last bandwidth change, is ignored.

The bandwidth indicated by the ETH-BN server includes the FCS; therefore, the include-fcs option must also be selected in the egress-rate command or the bandwidth will not match the intended rate.

For information on the egress-rate command, refer to the “Ethernet Commands” section in the 7705 SAR Interface Configuration Guide, “Configuration Command Reference” chapter.

3.1.9.5. ITU-T Y.1731 Performance Monitoring (PM)

The Y.1731 Performance Monitoring (PM) functions can be used to measure Ethernet frame delay, delay variation, throughput (including throughput at queue-rates), and frame loss. These performance parameters are defined for point-to-point Ethernet connections.

3.1.9.6. CFM OAM QoS

It is important that CFM OAM tools use the relevant FC and the associated queue to report traffic performance issues such as delay, jitter, and loss. When user traffic is mapped to one FC/queue and the OAM traffic is mapped to another FC/queue, data reported by the OAM tools might not be a true reflection of the performance metrics that the user traffic is experiencing, due mainly to different queue depths and scheduling priorities.

In order to ensure that CFM OAM traffic experiences the same treatment as user traffic, the 7705 SAR supports a configurable priority to specify the FC, and therefore the queue, to be used for a given OAM test. The priority keyword in the eth-cfm loopback, one-way-delay-test, single-ended-loss-test, two-way-delay-test and two-way-slm-test commands is used to configure the FC mapping as per the configured priority. The priority value maps to a specific FC; therefore, selecting a priority selects the FC. Table 5 lists the priority-to-FC mapping. This mapping of priority to FC cannot be changed by the user.

The priority-to-FC mapping does change depending on the message type and direction of the MEP. Table 6 summarizes the FC and Dot1p priority mappings based on this criteria.

For more information, refer to the 7705 SAR Services Guide, “Priority Mapping (802.1ag and Y.1731)”.

3.1.9.7. EFM OAM (802.3ah)

802.3ah Clause 57 defines the Ethernet in the First Mile (EFM) OAM sublayer, which is a link-level Ethernet OAM that is supported on 7705 SAR Ethernet ports configured as network or access ports. It provides mechanisms for monitoring link operations such as remote fault indication and remote loopback control. Ethernet OAM gives network operators the ability to monitor the health of Ethernet links and quickly determine the location of failing CFM links or fault conditions.

Because some of the sites where the 7705 SAR will be deployed will have only Ethernet uplinks, this OAM functionality is mandatory. For example, mobile operators must be able to request remote loopbacks from the peer router at the Ethernet layer in order to debug any connectivity issues. EFM OAM provides this capability.

EFM OAM defines a set of events that may impact link operation. The following events are supported:

These critical link events are signaled to the remote DTE by the flag field in OAMPDUs.

EFM OAM is supported on network and access Ethernet ports, and is configured at the Ethernet port level. The access ports can be configured to tunnel the OAM traffic originated by the far-end devices.

EFM OAM has the following characteristics.

The following EFM OAM functions are supported:

For information on Epipe service, refer to the 7705 SAR Services Guide, “Ethernet VLL (Epipe) Services”.

3.1.9.7.3. 802.3ah OAMPDU Tunneling and Termination for Epipe Services

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.

Note: This feature applies only to port-based Epipe SAPs because 802.3ah runs at port level, not at VLAN level.

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 Figure 16, 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.

3.1.10.1. Line and Internal Ethernet Loopbacks

A line loopback loops frames received on the corresponding port back towards the transmit direction. Line loopbacks are supported on ports configured for access or network mode.

Similarly, a line loopback with MAC addressing loops frames received on the corresponding port back towards the transmit direction, and swaps the source and destination MAC addresses before transmission. See MAC Swapping for more information.

An internal loopback loops frames from the local router back to the framer. This is usually referred to as an equipment loopback. The transmit signal is looped back and received by the interface. Internal loopbacks are supported on ports configured in access mode.

If a loopback is enabled on a port, the port mode cannot be changed until the loopback has been disabled.

A port can support only one loopback at a time. If a loopback exists on a port, it must be disabled or the timer must expire before another loopback can be configured on the same port. EFM-OAM cannot be enabled on a port that has an Ethernet loopback enabled on it. Similarly, an Ethernet loopback cannot be enabled on a port that has EFM-OAM enabled on it.

When an internal loopback is enabled on an Ethernet port, autonegotiation is turned off silently. This is to allow an internal loopback when the operational status of a port is down. Any user modification to autonegotiation on a port configured with an internal Ethernet loopback will not take effect until the loopback is disabled.

The loopback timer can be configured from 30 s to 86400 s. All non-zero timed loopbacks are turned off automatically under the following conditions: an adapter card reset, DSL module reset, GPON module reset, an activity switch, or timer expiry. Line or internal loopback timers can also be configured as a latched loopback by setting the timer to 0 s, or as a persistent loopback with the persistent keyword. Latched and persistent loopbacks are enabled indefinitely until turned off by the user. Latched loopbacks survive adapter card resets and activity switches, but are lost if there is a system restart. Persistent loopbacks survive adapter card resets and activity switches and can survive a system restart if the admin>save or admin>save>detail command was executed prior to the restart. Latched loopbacks (untimed) and persistent loopbacks can be enabled only on Ethernet access ports.

Persistent loopbacks are the only Ethernet loopbacks saved to the database by the admin>save and admin>save>detail commands.

3.1.10.2. CFM Loopbacks for OAM on Ethernet Ports

Connectivity fault management (CFM) loopback support for loopback messages (LBMs) on Ethernet ports allows operators to run standards-based Layer 1 and Layer 2 OAM tests on ports receiving unlabeled packets.

The 7705 SAR supports CFM MEPs associated with different endpoints (that is, spoke SDP down MEPs, and SAP up and SAP down MEPs). In addition, for traffic received from an uplink (network ingress), the 7705 SAR supports CFM LBM for both labeled and unlabeled packets. CFM loopbacks are applied to the Ethernet port.

See Ethernet OAM Capabilities for information on CFM MEPs.

Figure 18 shows an application where an operator leases facilities from a transport network provider in order to transport traffic from a cell site to their MTSO. The operator leases a certain amount of bandwidth between the two endpoints (the cell site and the MTSO) from the transport provider, who offers Ethernet Virtual Private Line (EVPL) or Ethernet Private Line (EPL) PTP service. Before the operator offers services on the leased bandwidth, the operator runs OAM tests to verify the SLA. Typically, the transport provider (MEN provider) requires that the OAM tests be run in the direction of (towards) the first Ethernet port that is connected to the transport network. This is done in order to eliminate the potential effect of queuing, delay, and jitter that may be introduced by a spoke SDP or SAP.

Figure 18:  CFM Loopback on Ethernet Ports 

Figure 18 shows an Ethernet verifier at the MTSO that is directly connected to the transport network (in front of the 7750 SR). Thus, the Ethernet OAM frames are not label- encapsulated. Given that Ethernet verifiers do not support label operations and the transport provider mandates that OAM tests be run between the two hand-off Ethernet ports, the verifier cannot be relocated behind the 7750 SR node at the MTSO. Therefore, CFM loopback frames received are not MPLS-encapsulated, but are simple Ethernet frames where the type is set to CFM (dot1ag or Y.1731).

3.1.11.1. ATM Ports

Propagation of ATM PW failures to the ATM port is achieved through the generation of AIS and RDI alarms.

3.1.11.2. T1/E1 TDM Ports

If a port on a 16-port T1/E1 ASAP Adapter card, 32-port T1/E1 ASAP Adapter card, or 2-port OC3/STM1 Channelized Adapter card is configured for CESoPSN VLL service, failure of the VLL forces a failure of the associated DS0s (timeslots). Since there can be n × DS0s bound to a CESoPSN VLL service as the attachment circuit, an alarm is propagated to the bound DS0s only. In order to emulate the failure, an “all 1s” or an “all 0s” signal is sent through the DS0s. The bit pattern can be configured to be either all 1s or all 0s. This is sometimes called “trunk conditioning”.

3.1.11.3. Ethernet Ports

For an Ethernet port-based Ethernet VLL, failure of the VLL forces a failure of the local Ethernet port. That is, the local attachment port is taken out of service at the physical layer and the Tx is turned off on the associated Ethernet port.

3.1.11.4. Pseudowire Status Signaling OAM Propagation

See the 7705 SAR Services Guide for more information about frame relay and HDLC PW status signaling and OAM propagation.

3.1.12.1. LDP Status via Label Withdrawal

Label withdrawal is negotiated during the PW status negotiation phase and needs to be supported by both the near-end and the far-end points. If the far end does not support label withdrawal, the 7705 SAR still withdraws the label in case the local attachment circuit is removed or shut down.

Label withdrawal occurs only when the attachment circuit is administratively shut down or deleted. If there is a failure of the attached circuit, the label withdrawal message is not generated.

When the local circuit is re-enabled after shutdown, the VLL must be re-established, which causes some delays and signaling overhead.

3.1.12.2. LDP Status via TLV

Signaling PW status via TLV is supported as per RFC 4447. Signaling PW status via TLV is advertised during the PW capabilities negotiation phase. It is more efficient and is preferred over the label withdrawal method.

For cell mode ATM PWs, when an AIS message is received from the local attachment circuit, the AIS message is propagated to the far-end PE unaltered and PW status TLV is not initiated.

3.1.13.1. Mtrace

Assessing problems in the distribution of IP multicast traffic can be difficult. The multicast traceroute (mtrace) feature uses a tracing feature implemented in multicast routers that is accessed via an extension to the IGMP protocol. The mtrace feature is used to print the path from the source to a receiver; it does this by passing a trace query hop-by-hop along the reverse path from the receiver to the source. At each hop, information such as the hop address, routing error conditions, and packet statistics are gathered and returned to the requester.

Data added by each hop includes:

The information enables the network administrator to determine:

When the trace response packet reaches the first-hop router (the router that is directly connected to the source’s network interface), that router sends the completed response to the response destination (receiver) address specified in the trace query.

If a multicast router along the path does not implement the mtrace feature or if there is an outage, then no response is returned. To solve this problem, the trace query includes a maximum hop count field to limit the number of hops traced before the response is returned. This allows a partial path to be traced.

The reports inserted by each router contain not only the address of the hop, but also the TTL required to forward the packets and flags to indicate routing errors, plus counts of the total number of packets on the incoming and outgoing interfaces and those forwarded for the specified group. Examining the differences in these counts for two separate traces and comparing the output packet counts from one hop with the input packet counts of the next hop allows the calculation of packet rate and packet loss statistics for each hop to isolate congestion problems.

3.1.13.2. Mstat

The mstat feature adds the capability to show the multicast path in a limited graphic display and indicates drops, duplicates, TTLs, and delays at each node. This information is useful to the network operator because it identifies nodes with high drop and duplicate counts. Duplicate counts are shown as negative drops.

The output of mstat provides a limited pictorial view of the path in the forward direction with data flow indicated by arrows pointing downward and the query path indicated by arrows pointing upward. For each hop, both the entry and exit addresses of the router are shown if different, along with the initial TTL required on the packet in order to be forwarded at this hop and the propagation delay across the hop assuming that the routers at both ends have synchronized clocks. The output consists of two columns, one for the overall multicast packet rate that does not contain lost/sent packets and the other for the (S,G)-specific case. The (S,G) statistics also do not contain lost/sent packets.

3.1.13.3. Mrinfo

The mrinfo feature is a simple mechanism to display the configuration information from the target multicast router. The type of information displayed includes the multicast capabilities of the router, code version, metrics, TTL thresholds, protocols, and status. This information can be used by network operators, for example, to verify if bidirectional adjacencies exist. Once the specified multicast router responds, the configuration is displayed.

3.2.3.1. Writing SAA Ethernet CFM Test Results to Accounting Files

When each SAA CFM test is completed, the 7705 SAR collects the results in an accounting file that can be accessed by the network management system. In order to write the SAA test results to an accounting file in a compressed XML format, the results must be collected and entered in the appropriate MIB table, and a record must be generated in the appropriate accounting file.

Refer to the 7705 SAR System Management Guide, “Configuring an Accounting Policy” section, for information about creating accounting files and writing to them.

Once an accounting file has been created, accounting information can be specified and collected under the config>log>acct-policy>to file log-file-id context.