OAM and SAA

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 instead of 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 about SGT redirection, see the 7705 SAR Quality of Service Guide, "SGT Redirection".

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

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

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 tests to be executed

• the security protocol to be used

• the port to be used

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

• timestamps the TWAMP packets upon reception

• processes the TWAMP packets and generates a response

• timestamps the packets again before transmitting the response packets

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:

• adapter cards

  • 2-port 10GigE (Ethernet) Adapter card

  • 6-port Ethernet 10Gbps Adapter card (high accuracy when using IEEE 1588v2 PTP time source)

  • 8-port Gigabit Ethernet Adapter card (high accuracy when using IEEE 1588v2 PTP time source)

  • 10-port 1GigE/1-port 10GigE X-Adapter card (high accuracy when using IEEE 1588v2 PTP time source)

  • Packet Microwave Adapter card (high accuracy when using IEEE 1588v2 PTP time source)

• modules

  • 2-port 10GigE (Ethernet) module

  • 4-port SAR-H Fast Ethernet module

  • 6-port SAR-M Ethernet module

• standalone nodes

  • 7705 SAR-A (high accuracy when using IEEE 1588v2 PTP time source)

  • 7705 SAR-Ax (high accuracy when using IEEE 1588v2 PTP time source)

  • 7705 SAR-H (high accuracy when using IEEE 1588v2 PTP time source)

  • 7705 SAR-Hc (high accuracy when using IEEE 1588v2 PTP time source)

  • 7705 SAR-M (high accuracy when using IEEE 1588v2 PTP time source)

  • 7705 SAR-Wx (high accuracy when using IEEE 1588v2 PTP time source)

  • 7705 SAR-X (high accuracy when using IEEE 1588v2 PTP time source)

CSM-based egress timestamping for TWAMP is supported on:

• all TDM cards

  • 2-port OC3/STM1 Channelized Adapter card

  • 4-port DS3/E3 Adapter card

  • 4-port OC3/STM1 Clear Channel Adapter card

  • 16-port T1/E1 ASAP Adapter card

  • 32-port T1/E1 ASAP Adapter card

• Ethernet ports bound to a routed VPLS interface, where the frames are processed via the VPLS instance before reaching the IP interface

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.

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>test-oam>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 use 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.

LSP ping, as described in RFC 4379, provides a mechanism to detect data plane failures in MPLS LSPs. For a specified 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. See the 7705 SAR Basic System Configuration Guide, "Node Timing", for information about node timing sources.

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

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. The following figure shows the new TLV structure.

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

1. The next hop of a BGP labeled route for a core IPv4 /32 prefix is always resolved to an LDP FEC or an RSVP-TE LSP. The transmitting node encapsulates the packet containing the echo request message with a label stack that consists of the LDP/RSVP-TE outer label and the BGP inner label.

2. If the packet expires on an RSVP-TE or LDP LSR node that does not have context for the BGP labeled IPv4 /32 prefix, the system must validate the outer label in the stack, and if the validation is successful, it must reply with return code 8 <Label switched at stack-depth <RSC>>.

3. An LSR node that is the next hop for the BGP labeled IPv4 /32 prefix, as well as the LER node that originated the BGP labeled IPv4 prefix, have full context for the BGP IPv4 target FEC stack and can therefore perform full validation of it.

For more information about BGP route tunnels, see the 7705 SAR Routing Protocols Guide, "BGP Route Tunnels".

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. The following figure shows the DDMAP TLV format.

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

1. When either the DSMAP TLV or the DDMAP TLV is received in an echo request message, the responder node includes the same type of TLV in the echo reply message with the correct downstream interface information and label stack information.

2. If an echo request message without a DSMAP or DDMAP TLV expires at a node that is not the egress for the target FEC stack, the responder node always includes the DSMAP TLV in the echo reply message. This can occur in the following cases:

   1. The user issues an LSP trace from a sender node with a min-ttl value higher than 1 and a max-ttl value lower than the number of hops required to reach the egress of the target FEC stack. This is the sender node behavior when the global configuration or the per-test setting of the DSMAP/DDMAP is set to DSMAP.

   2. The user issues an LSP ping from a sender node with a TTL value lower than the number of hops required to reach the egress of the target FEC stack. This is the sender node behavior when the global configuration of the DSMAP/DDMAP is set to DSMAP.

   3. If the global configuration or the per-test setting of the DSMAP TLV is set to DDMAP, the sender node includes the DDMAP TLV with the downstream IP address field set to the all-routers multicast address as per Section 3.3 of RFC 4379. The responder node then bypasses the interface and label stack validation and replies with a DDMAP TLV with the correct downstream information for the target FEC stack.

3. A sender node never includes the DSMAP or DDMAP TLV in an LSP ping message.

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.

This section describes how MPLS OAM models the SR tunnel types.

An SR shortest path tunnel, SR-ISIS tunnel, or SR-OSPF tunnel uses a single FEC element in the target FEC stack TLV. The FEC corresponds to the prefix of the SID in a specific IGP instance.

The following figure shows the format for the IPv4 IGP prefix SID.

The fields are defined as follows:

• IPv4 Prefix

  This field carries the IPv4 prefix to which the SID is assigned. If the prefix is shorter than 32 bits, trailing bits must be set to 0.

• Prefix Length

  This field is one octet and gives the length of the prefix in bits (values can be from 1 to 32).

• Protocol

  This field is set to 1 when the IGP is OSPF and set to 2 when the IGP is IS-IS.

The following figure shows the format for the IPv6 IGP prefix SID.

The fields are defined as follows:

• IPv6 Prefix

  This field carries the IPv6 prefix to which the SID is assigned. If the prefix is shorter than 128 bits, trailing bits must be set to 0.

• Prefix Length

  This field is one octet and gives the length of the prefix in bits (values can be from 1 to 128).

• Protocol

  This field is set to 1 when the IGP protocol is OSPF and set to 2 when the IGP protocol is IS-IS.

As a hierarchical LSP, an SR-TE LSP uses the target FEC stack TLV, which contains a FEC element for each node SID and each adjacency SID in the path of the SR-TE LSP. Because the SR-TE LSP does not instantiate a state in the LSR other than the ingress LSR, MPLS OAM tests a hierarchy of node SID and adjacency SID segments toward the destination of the SR-TE LSP. IPv6 IGP prefix SID shows the format for the node SID. The following figure shows the format for the IGP Adjacency SID.

The fields are defined as follows:

• Adj. Type (Adjacency Type)

  This field is set to 1 when the adjacency segment is a parallel adjacency as defined in draft.ietf-spring-segment-routing. This field is set to 4 when the adjacency segment is IPv4-based and is not a parallel adjacency. This field is set to 6 when the adjacency segment is IPv6-based and is not a parallel adjacency.

• Protocol

  This field is set to 1 when the IGP protocol is OSPF and set to 2 when the IGP protocol is IS-IS.

• Local Interface ID

  This field is an identifier that is assigned by the local LSR for a link on which the adjacency SID is bound. This field is set to a local link address (IPv4 or IPv6). If unnumbered, the 32-bit link identifier defined in RFC 4203 and RFC 5307 is used. If the adjacency SID represents parallel adjacencies, as described in draft.ietf-spring-segment-routing, this field must be set to 0.

• Remote Interface ID

  This field is an identifier that is assigned by the remote LSR for a link on which the adjacency SID is bound. This field is set to the remote (downstream neighbor) link address (IPv4 or IPv6). If unnumbered, the 32-bit link identifier defined in RFC 4203 and RFC 5307 is used. If the adjacency SID represents parallel adjacencies, as described in draft.ietf-spring-segment-routing, this field must be set to 0.

• Advertising Node Identifier

  This field specifies the advertising node identifier. When the Protocol field is set to 1, the 32 rightmost bits represent the OSPF router ID. When the Protocol field is set to 2, this field carries the 48-bit IS-IS system ID.

• Receiving Node Identifier

  This field specifies the downstream node identifier. When the Protocol field is set to 1, the 32 rightmost bits represent the OSPF router ID. When the Protocol field is set to 2, this field carries the 48-bit IS-IS system ID.

Both lsp-ping and lsp-trace apply to the following contexts:

• SR-ISIS or SR-OSPF shortest path IPv4 tunnel

• SR-ISIS shortest path IPv6 tunnel

• IS-IS SR-TE IPv4 LSP or OSPF SR-TE IPv4 LSP

• BGP IPv4 LSP resolved over an SR-ISIS IPv4 tunnel, an SR-OSPF IPv4 tunnel, or an SR-TE IPv4 LSP, including support for BGP LSP across AS boundaries and for ECMP next hops at the transport tunnel level

The following operations apply to lsp-ping and lsp-trace commands on SR-ISIS tunnels or SR-OSPF tunnels:

• The sender node builds the target FEC stack TLV with a single FEC element corresponding to the node SID of the destination of the SR-ISIS or SR-OSPF tunnel.

• A node SID label that is swapped at an LSR results in a return code of 8, ‟Label switched at stack-depth <RSC>”, per RFC 8029.

• A node SID label that is popped at an LSR results in a return code of 3, ‟Replying router is an egress for the FEC at stack-depth <RSC>”.

• The lsp-trace command supports the following downstream mapping TLV parameters: ddmap, dsmap, or none. When the downstream mapping TLV is configured as none, no map TLV is sent. The downstream interface information is returned along with the egress label for the node SID tunnel and the protocol that resolved the node SID at the responder node.

The following figure shows an example of the topology used for LSP ping and LSP trace for an SR-ISIS node SID tunnel.

Based on this topology, the following is an output example for LSP ping on DUT-A for target node SID of DUT-F:

*A:Dut-A# oam lsp-ping sr-isis prefix 10.20.1.6/32 igp-instance 0 detail
LSP-PING 10.20.1.6/32: 80 bytes MPLS payload
Seq=1, send from intf int_to_B, reply from 10.20.1.6
       udp-data-len=32 ttl=255 rtt=1220324ms rc=3 (EgressRtr)
---- LSP 10.20.1.6/32 PING Statistics ----
1 packets sent, 1 packets received, 0.00% packet loss
round-trip min = 1220324ms, avg = 1220324ms, max = 1220324ms, stddev = 0.000ms

The following is an output example for LSP trace on DUT-A for target node SID of DUT-F (DSMAP TLV):

*A:Dut-A# oam lsp-trace sr-isis prefix 10.20.1.6/32 igp-instance 0 downstream-map-tlv dsmap detail
lsp-trace to 10.20.1.6/32: 0 hops min, 0 hops max, 108 byte packets
1  10.20.1.2  rtt=1220323ms rc=8(DSRtrMatchLabel) rsc=1
     DS 1: ipaddr=10.10.4.4 ifaddr=10.10.4.4 iftype=ipv4Numbered MRU=1496
           label[1]=26406 protocol=6(ISIS)
2  10.20.1.4  rtt=1220323ms rc=8(DSRtrMatchLabel) rsc=1
     DS 1: ipaddr=10.10.9.6 ifaddr=10.10.9.6 iftype=ipv4Numbered MRU=1496
           label[1]=26606 protocol=6(ISIS)
3  10.20.1.6  rtt=1220324ms rc=3(EgressRtr) rsc=1

The following is an output example for LSP trace on DUT-A for target node SID of DUT-F (DDMAP TLV):

*A:Dut-A# oam lsp-trace sr-isis prefix 10.20.1.6/32 igp-instance 0 downstream-map-tlv ddmap detail
lsp-trace to 10.20.1.6/32: 0 hops min, 0 hops max, 108 byte packets
1  10.20.1.2  rtt=1220323ms rc=8(DSRtrMatchLabel) rsc=1
     DS 1: ipaddr=10.10.4.4 ifaddr=10.10.4.4 iftype=ipv4Numbered MRU=1496
           label[1]=26406 protocol=6(ISIS)
2  10.20.1.4  rtt=1220324ms rc=8(DSRtrMatchLabel) rsc=1
     DS 1: ipaddr=10.10.9.6 ifaddr=10.10.9.6 iftype=ipv4Numbered MRU=1496
           label[1]=26606 protocol=6(ISIS)
3  10.20.1.6  rtt=1220324ms rc=3(EgressRtr) rsc=1

The following operations apply to lsp-ping and lsp-trace commands on SR-TE LSPs:

• The sender node builds a target FEC stack TLV that contains FEC elements.

  For lsp-ping, the target FEC stack TLV contains a single FEC element that corresponds to the last segment, that is, a node SID or an adjacency SID of the destination of the SR-TE LSP.

  For lsp-trace, the target FEC stack TLV contains a FEC element for each node SID and for each adjacency SID in the path of the SR-TE LSP, including the SID of the destination of the SR-TE LSP.

• A node SID label that is popped at an LSR results in a return code of 3, ‟Replying router is an egress for the FEC at stack-depth <RSC>”.

• An adjacency SID label that is popped at an LSR results in a return code of 3, ‟Replying router is an egress for the FEC at stack-depth <RSC>”.

• A node SID label that is swapped at an LSR results in a return code of 8, ‟Label switched at stack-depth <RSC>”, per RFC 8029.

• An adjacency SID label that is swapped at an LSR results in a return code of 8, ‟Label switched at stack-depth <RSC>”, per RFC 8029.

• The lsp-trace command includes the option to specify the downstream mapping TLV format to use in the LSP trace packet: ddmap, dsmap, or none. When none is configured, no map TLV is sent. The downstream interface information is returned along with the egress label for the node SID tunnel or the adjacency SID tunnel of the current segment as well as the protocol that resolved the tunnel at the responder node.

• If the target FEC stack TLV contains more than one FEC element, the responder node that is the termination of one node SID or adjacency SID segment pops its own SID in the first operation. When the sender node receives this reply, it adjusts the target FEC stack TLV by stripping the top FEC before sending the probe for the next TTL value. When the responder node receives the next echo request message with the same TTL value from the sender node for the next node SID or adjacency SID segment in the stack, it performs a swap operation to that next segment.

• When the path of the SR-TE LSP is computed by the sender node, the hop-to-label translation tool returns the IGP instance that was used to determine the labels for each hop in the path. When the path of the SR-TE LSP is computed by a PCE, the protocol ID is not returned by the PCEP. In this case, the sender node performs a lookup in the SR module for the IGP instance that resolved the first segment of the path. In both cases, the IGP is used to encode the protocol ID field of the node SID or adjacency SID in each of the FEC elements of the target FEC stack TLV.

• The responder node validates the top FEC in the target FEC stack TLV, provided that the depth of the incoming label stack in the packet header is greater than the depth of the target FEC stack TLV.

• TTL values can be changed.

  The ttl parameter in the lsp-ping command can be set to a value lower than 255 and the responder node replies if the FEC element in the target FEC stack TLV corresponds to a node SID resolved at that node. The responder node, however, fails the validation if the FEC element in the target FEC stack TLV is the adjacency of a remote node. The return code in the echo reply message is either ‟rc=4(NoFECMapping)” or ‟rc=10(DSRtrUnmatchLabel)”.

  The min-ttl and max-ttl parameters in the lsp-trace command can be set to values other than the default. However, lsp-trace can only properly trace the partial path of an SR-TE LSP if there is no segment termination before the node that corresponds to the minimum TTL value. Otherwise, it fails validation and returns an error because the responder node receives a target FEC stack depth that is greater than the incoming label stack size. The return code in the echo reply message is ‟rc=4(NoFECMapping)”, ‟rc=5(DSMappingMismatched)”, or ‟rc=10(DSRtrUnmatchLabel)”.

  This scenario is true whether the downstream-map-tlv option is set to ddmap, dsmap, or none.

The following are output examples for LSP ping and LSP trace on SR-TE LSPs. The first example uses a path with strict hops, each corresponding to an adjacency SID, while the second example uses a path with loose hops, each corresponding to a node SID. The topology for the examples is shown in the following figure.

Example 1

The following output is an example of LSP ping and LSP trace on DUT-A for a strict-hop adjacency SID SR-TE LSP, where:

• the source is DUT-A

• the destination is DUT-F

• the path is as follows: A to B, B to C, C to E, E to D, D to F

*A:Dut-A# oam lsp-ping sr-te "srteABCEDF" detail
LSP-PING srteABCEDF: 96 bytes MPLS payload
Seq=1, send from intf int_to_B, reply from 10.20.1.6
       udp-data-len=32 ttl=255 rtt=1220325ms rc=3 (EgressRtr)
---- LSP srteABCEDF PING Statistics ----
1 packets sent, 1 packets received, 0.00% packet loss
round-trip min = 1220325ms, avg = 1220325ms, max = 1220325ms, stddev = 0.000ms
*A:Dut-A# oam lsp-trace sr-te "srteABCEDF" downstream-map-tlv ddmap detail
lsp-trace to srteABCEDF: 0 hops min, 0 hops max, 252 byte packets
1  10.20.1.2  rtt=1220323ms rc=3(EgressRtr) rsc=5
1  10.20.1.2  rtt=1220322ms rc=8(DSRtrMatchLabel) rsc=4
     DS 1: ipaddr=10.10.33.3 ifaddr=10.10.33.3 iftype=ipv4Numbered MRU=1520
           label[1]=3 protocol=6(ISIS)
           label[2]=262135 protocol=6(ISIS)
           label[3]=262134 protocol=6(ISIS)
           label[4]=262137 protocol=6(ISIS)
2  10.20.1.3  rtt=1220323ms rc=3(EgressRtr) rsc=4
2  10.20.1.3  rtt=1220323ms rc=8(DSRtrMatchLabel) rsc=3
     DS 1: ipaddr=10.10.5.5 ifaddr=10.10.5.5 iftype=ipv4Numbered MRU=1496
           label[1]=3 protocol=6(ISIS)
           label[2]=262134 protocol=6(ISIS)
           label[3]=262137 protocol=6(ISIS)
3  10.20.1.5  rtt=1220325ms rc=3(EgressRtr) rsc=3
3  10.20.1.5  rtt=1220325ms rc=8(DSRtrMatchLabel) rsc=2
     DS 1: ipaddr=10.10.11.4 ifaddr=10.10.11.4 iftype=ipv4Numbered MRU=1496
           label[1]=3 protocol=6(ISIS)
           label[2]=262137 protocol=6(ISIS)
4  10.20.1.4  rtt=1220324ms rc=3(EgressRtr) rsc=2
4  10.20.1.4  rtt=1220325ms rc=8(DSRtrMatchLabel) rsc=1
     DS 1: ipaddr=10.10.9.6 ifaddr=10.10.9.6 iftype=ipv4Numbered MRU=1496
           label[1]=3 protocol=6(ISIS)
5  10.20.1.6  rtt=1220325ms rc=3(EgressRtr) rsc=1

Example 2

The following output is an example of LSP ping and LSP trace on DUT-A for a loose-hop node SID SR-TE LSP, where:

• the source is DUT-A

• the destination is DUT-F

• the path is A, B, C, E

*A:Dut-A# oam lsp-ping sr-te "srteABCE_loose" detail
LSP-PING srteABCE_loose: 80 bytes MPLS payload
Seq=1, send from intf int_to_B, reply from 10.20.1.5
       udp-data-len=32 ttl=255 rtt=1220324ms rc=3 (EgressRtr)
---- LSP srteABCE_loose PING Statistics ----
1 packets sent, 1 packets received, 0.00% packet loss
round-trip min = 1220324ms, avg = 1220324ms, max = 1220324ms, stddev = 0.000ms
*A:Dut-A# oam lsp-trace sr-te "srteABCE_loose" downstream-map-tlv ddmap detail
lsp-trace to srteABCE_loose: 0 hops min, 0 hops max, 140 byte packets
1  10.20.1.2  rtt=1220323ms rc=3(EgressRtr) rsc=3
1  10.20.1.2  rtt=1220322ms rc=8(DSRtrMatchLabel) rsc=2
     DS 1: ipaddr=10.10.3.3 ifaddr=10.10.3.3 iftype=ipv4Numbered MRU=1496
           label[1]=26303 protocol=6(ISIS)
           label[2]=26305 protocol=6(ISIS)
     DS 2: ipaddr=10.10.12.3 ifaddr=10.10.12.3 iftype=ipv4Numbered MRU=1496
           label[1]=26303 protocol=6(ISIS)
           label[2]=26305 protocol=6(ISIS)
     DS 3: ipaddr=10.10.33.3 ifaddr=10.10.33.3 iftype=ipv4Numbered MRU=1496
           label[1]=26303 protocol=6(ISIS)
           label[2]=26305 protocol=6(ISIS)
2  10.20.1.3  rtt=1220323ms rc=3(EgressRtr) rsc=2
2  10.20.1.3  rtt=1220323ms rc=8(DSRtrMatchLabel) rsc=1
     DS 1: ipaddr=10.10.5.5 ifaddr=10.10.5.5 iftype=ipv4Numbered MRU=1496
           label[1]=26505 protocol=6(ISIS)
     DS 2: ipaddr=10.10.11.5 ifaddr=10.10.11.5 iftype=ipv4Numbered MRU=1496
           label[1]=26505 protocol=6(ISIS)
3  10.20.1.5  rtt=1220324ms rc=3(EgressRtr) rsc=1

The 7705 SAR supports LSP ping and LSP trace on a BGP IPv4 LSP resolved over an SR-OSPF IPv4 tunnel, an SR-ISIS IPv4 tunnel, or an SR-TE IPv4 LSP.

The following are output examples of LSP trace for a hierarchical tunnel consisting of a BGP IPv4 LSP resolved over an SR-OSPF IPv4 tunnel, an SR-ISIS IPv4 tunnel, or an SR-TE IPv4 LSP (OSPF or IS-IS). The topology for the examples is shown in the following figure.

Output example for BGP over SR-OSPF:

*A:Dut-A# oam lsp-trace bgp-label prefix 11.21.1.6/32 detail downstream-map-tlv ddmap path-destination 127.1.1. 
lsp-trace to 11.21.1.6/32: 0 hops min, 0 hops max, 168 byte packets
1  10.20.1.3  rtt=2.31ms rc=8(DSRtrMatchLabel) rsc=2 
     DS 1: ipaddr=10.10.5.5 ifaddr=10.10.5.5 iftype=ipv4Numbered MRU=1496 
           label[1]=27506 protocol=5(OSPF)
           label[2]=13199 protocol=2(BGP)
     DS 2: ipaddr=10.10.11.4 ifaddr=10.10.11.4 iftype=ipv4Numbered MRU=1496 
           label[1]=27406 protocol=5(OSPF)
           label[2]=262137 protocol=2(BGP)
     DS 3: ipaddr=10.10.11.5 ifaddr=10.10.11.5 iftype=ipv4Numbered MRU=1496 
           label[1]=27506 protocol=5(OSPF)
           label[2]=262137 protocol=2(BGP)
2   10.20.1.4  rtt=4.91ms rc=8(DSRtrMatchLabel) rsc=2 
     DS 1: ipaddr=10.10.9.6 ifaddr=10.10.9.6 iftype=ipv4Numbered MRU=1492 
           label[1]=27606 protocol=5(OSPF)
           label[2]=262137 protocol=2(BGP)
3  10.20.1.6  rtt=4.73ms rc=3(EgressRtr) rsc=2 
3  10.20.1.6  rtt=5.44ms rc=3(EgressRtr) rsc=1 
*A:Dut-A# 

Output example for BGP over SR-TE (OSPF):

*A:Dut-A# oam lsp-trace bgp-label prefix 11.21.1.6/32 detail downstream-map-tlv ddmap path-destination 127.1.1.1 
lsp-trace to 11.21.1.6/32: 0 hops min, 0 hops max, 236 byte packets
1  10.20.1.2  rtt=2.13ms rc=3(EgressRtr) rsc=4 
1  10.20.1.2  rtt=1.79ms rc=8(DSRtrMatchLabel) rsc=3 
     DS 1: ipaddr=10.10.4.4 ifaddr=10.10.4.4 iftype=ipv4Numbered MRU=1492 
           label[1]=3 protocol=5(OSPF)
           label[2]=262104 protocol=5(OSPF)
           label[3]=262139 protocol=2(BGP)
2  10.20.1.4  rtt=3.24ms rc=3(EgressRtr) rsc=3 
2  10.20.1.4  rtt=4.46ms rc=8(DSRtrMatchLabel) rsc=2 
     DS 1: ipaddr=10.10.9.6 ifaddr=10.10.9.6 iftype=ipv4Numbered MRU=1492 
           label[1]=3 protocol=5(OSPF)
           label[2]=262139 protocol=2(BGP)
3  10.20.1.6  rtt=6.24ms rc=3(EgressRtr) rsc=2 
3  10.20.1.6  rtt=6.18ms rc=3(EgressRtr) rsc=1 
*A:Dut-A# 

Output example for BGP over SR-ISIS:

A:Dut-A# oam lsp-trace bgp-label prefix 11.21.1.6/32 detail downstream-map-tlv ddmap path-destination 127.1.1.1 
lsp-trace to 11.21.1.6/32: 0 hops min, 0 hops max, 168 byte packets
1  10.20.1.3  rtt=3.33ms rc=8(DSRtrMatchLabel) rsc=2 
    DS 1:  ipaddr=10.10.5.5 ifaddr=10.10.5.5 iftype=ipv4Numbered MRU=1496 
           label[1]=28506 protocol=6(ISIS)
           label[2]=262139 protocol=2(BGP)
     DS 2: ipaddr=10.10.11.4 ifaddr=10.10.11.4 iftype=ipv4Numbered MRU=1496 
           label[1]=28406 protocol=6(ISIS)
           label[2]=262139 protocol=2(BGP)
     DS 3: ipaddr=10.10.11.5 ifaddr=10.10.11.5 iftype=ipv4Numbered MRU=1496 
           label[1]=28506 protocol=6(ISIS)
           label[2]=262139 protocol=2(BGP)
2  10.20.1.4  rtt=5.12ms rc=8(DSRtrMatchLabel) rsc=2 
     DS 1: ipaddr=10.10.9.6 ifaddr=10.10.9.6 iftype=ipv4Numbered MRU=1492 
           label[1]=28606 protocol=6(ISIS)
           label[2]=262139 protocol=2(BGP)
3  10.20.1.6  rtt=8.41ms rc=3(EgressRtr) rsc=2 
3  10.20.1.6  rtt=6.93ms rc=3(EgressRtr) rsc=1 

Output example for BGP over SR-TE (ISIS):

*A:Dut-A# oam lsp-trace bgp-label prefix 11.21.1.6/32 detail downstream-map-tlv ddmap path-destination 127.1.1.1 
lsp-trace to 11.21.1.6/32: 0 hops min, 0 hops max, 248 byte packets
1  10.20.1.2  rtt=2.60ms rc=3(EgressRtr) rsc=4 
1  10.20.1.2  rtt=2.29ms rc=8(DSRtrMatchLabel) rsc=3 
     DS 1: ipaddr=10.10.4.4 ifaddr=10.10.4.4 iftype=ipv4Numbered MRU=1492 
           label[1]=3 protocol=6(ISIS)
           label[2]=262094 protocol=6(ISIS)
           label[3]=262139 protocol=2(BGP)
2  10.20.1.4  rtt=4.04ms rc=3(EgressRtr) rsc=3 
2  10.20.1.4  rtt=4.38ms rc=8(DSRtrMatchLabel) rsc=2 
     DS 1: ipaddr=10.10.9.6 ifaddr=10.10.9.6 iftype=ipv4Numbered MRU=1492 
           label[1]=3 protocol=6(ISIS)
           label[2]=262139 protocol=2(BGP)
3  10.20.1.6  rtt=6.64ms rc=3(EgressRtr) rsc=2 
3  10.20.1.6  rtt=5.94ms rc=3(EgressRtr) rsc=1

Assuming the topology in the following figure has the addition of an EBGP peering between nodes B and C, the BGP IPv4 LSP spans the AS boundary and resolves to an SR-ISIS tunnel or an SR-TE LSP within each AS.

Output example for BGP over SR-ISIS in inter-AS option C:

*A:Dut-A# oam lsp-trace bgp-label prefix 11.20.1.6/32 src-ip-address 11.20.1.1 detail downstream-map-tlv ddmap path-destination 127.1.1.1 
lsp-trace to 11.20.1.6/32: 0 hops min, 0 hops max, 168 byte packets
1  10.20.1.2  rtt=2.69ms rc=3(EgressRtr) rsc=2 
1  10.20.1.2  rtt=3.15ms rc=8(DSRtrMatchLabel) rsc=1 
     DS 1: ipaddr=10.10.3.3 ifaddr=10.10.3.3 iftype=ipv4Numbered MRU=0 
           label[1]=262127 protocol=2(BGP)
2  10.20.1.3  rtt=5.26ms rc=15(LabelSwitchedWithFecChange) rsc=1 
     DS 1: ipaddr=10.10.5.5 ifaddr=10.10.5.5 iftype=ipv4Numbered MRU=1496 
           label[1]=26506 protocol=6(ISIS)
           label[2]=262139 protocol=2(BGP)
           fecchange[1]=PUSH fectype=SR Ipv4 Prefix prefix=10.20.1.6 
remotepeer=10.10.5.5 
3  10.20.1.5  rtt=7.08ms rc=8(DSRtrMatchLabel) rsc=2 
     DS 1: ipaddr=10.10.10.6 ifaddr=10.10.10.6 iftype=ipv4Numbered MRU=1496 
           label[1]=26606 protocol=6(ISIS)
       label[2]=262139 protocol=2(BGP)
4  10.20.1.6  rtt=9.41ms rc=3(EgressRtr) rsc=2 
4  10.20.1.6  rtt=9.53ms rc=3(EgressRtr) rsc=1

Output example for BGP over SR-TE (ISIS) in inter-AS option C:

*A:Dut-A# oam lsp-trace bgp-label prefix 11.20.1.6/32 src-ip-address 11.20.1.1 detail downstream-map-tlv ddmap path-destination 127.1.1.1 
lsp-trace to 11.20.1.6/32: 0 hops min, 0 hops max, 168 byte packets
1  10.20.1.2  rtt=2.77ms rc=3(EgressRtr) rsc=2 
1  10.20.1.2  rtt=2.92ms rc=8(DSRtrMatchLabel) rsc=1 
     DS 1: ipaddr=10.10.3.3 ifaddr=10.10.3.3 iftype=ipv4Numbered MRU=0 
           label[1]=262127 protocol=2(BGP)
2  10.20.1.3  rtt=4.82ms rc=15(LabelSwitchedWithFecChange) rsc=1 
     DS 1: ipaddr=10.10.5.5 ifaddr=10.10.5.5 iftype=ipv4Numbered MRU=1496 
           label[1]=26505 protocol=6(ISIS)
           label[2]=26506 protocol=6(ISIS)
           label[3]=262139 protocol=2(BGP)
           fecchange[1]=PUSH fectype=SR Ipv4 Prefix prefix=10.20.1.6 
remotepeer=0.0.0.0 (Unknown)
           fecchange[2]=PUSH fectype=SR Ipv4 Prefix prefix=10.20.1.5            
remotepeer=10.10.5.5 
3  10.20.1.5  rtt=7.10ms rc=3(EgressRtr) rsc=3 
3  10.20.1.5  rtt=7.45ms rc=8(DSRtrMatchLabel) rsc=2 
     DS 1: ipaddr=10.10.10.6 ifaddr=10.10.10.6 iftype=ipv4Numbered MRU=1496 
           label[1]=26606 protocol=6(ISIS)
           label[2]=262139 protocol=2(BGP)
4  10.20.1.6  rtt=9.23ms  c=3(EgressRtr) rsc=2 
4  10.20.1.6  rtt=9.46ms rc=3(EgressRtr) rsc=1 
*A:Dut-A

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:

• the egress SDP ID encapsulation

• the ability to reach the far-end IP address of the SDP ID within the SDP encapsulation

• the path MTU to the far-end IP address over the SDP ID

• the forwarding class mapping between the near-end SDP ID encapsulation and the far-end tunnel termination

For a round-trip test, SDP ping uses a local egress SDP ID and an expected remote SDP ID. Because 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:

• the remote SDP ID encapsulation

• the potential service round-trip time

• the round-trip path MTU

• the round-trip forwarding class mapping

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 MTU path 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.

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:

• tunnel connectivity

• VC label mapping verification

• service existence

• service provisioned parameter verification

• round-trip path verification

• service dynamic configuration verification

  Note: By default, service ping uses GRE encapsulation.

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. See the 7705 SAR Basic System Configuration Guide, "Node Timing", for information about node timing sources.

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

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, see 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.

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 the following table).

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. See the 7705 SAR Basic System Configuration Guide, "Node Timing", for information about node timing sources.

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.

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

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.

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.

The 7705 SAR supports the following Ethernet OAM capabilities:

• Ethernet connectivity fault management (ETH-CFM) – for network layer OAM according to IEEE 802.1ag (dot1ag) and ITU Y.1731 standards, including loopback (LB), linktrace (LT), continuity check (CC), and remote defect indication (RDI). "Network layer" refers to an end-to-end context across a network.

  ITU-T Y.1731 provides functional enhancements to 802.1ag ETH-CFM, including alarm indication signals (AIS) and Ethernet signal tests (ETH-Test).

  See ETH-CFM Ethernet OAM tests (802.1ag and Y.1731).

• performance monitoring (PM) – PM according to the ITU-T Y.1731 standard, including delay measurements (DM), delay variation measurements (DV), and loss measurements (LM)

  See ITU-T Y.1731 performance monitoring (PM).

• Ethernet bandwidth notification (ETH-BN) – when enabled on a port, the egress rate may be dynamically altered based on the available bandwidth indicated by the ETH-BN server.

  See ITU-T Y.1731 Ethernet bandwidth notification (ETH-BN).

• Ethernet first mile (EFM) OAM – for the transport layer OAM according to IEEE 802.3ah (dot3ah) standards. "Transport layer" refers to a point-to-point link context or transport hop.

  See EFM OAM (802.3ah).

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 CSM switchovers.

The following table 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.

The following table lists the MEPs that support each test.

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:

• loss of connectivity

• unidirectional loss

• loops

• merging of services

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

• Ethernet alarm indication signal (ETH-AIS)

• Ethernet test function (ETH-Test)

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 (Epipes and VPLS) or network interface level. The following entities and their configuration levels are listed below:

• global level

  • MA and MEG

  • MD

  • MD level and MEG level

• Ethernet service level

  • MEP

• Ethernet network interface level

  • facility MEP

For information about configuring ETH-CFM to set up an Ethernet OAM architecture, see 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 about ETH-CFM support specific to network interfaces,see the 7705 SAR Router Configuration Guide, "ETH-CFM Support".

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.

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 an Ethernet bandwidth notification message (ETH-BNM), 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 is interoperating with 9500 MPR-e radios, ETH-BN functionality is supported with 9500 MPR-e radios in standalone mode or in MWA mode.

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:

• 8-port Gigabit Ethernet Adapter card

• 10-port 1GigE/1-port 10GigE X-Adapter card

• Packet Microwave Adapter card

• 6-port Ethernet 10Gbps Adapter card

• 2-port 10GigE (Ethernet) Adapter card (v-port)

• 2-port 10GigE (Ethernet) module (v-port)

• 6-port SAR-M Ethernet module

• all fixed platforms, with the exception of Fast Ethernet ports on the 7705 SAR-A (ports 9 to 12)

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. 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 about the egress-rate command, see the ‟Ethernet commands” section in the 7705 SAR Interface Configuration Guide, ‟Configuration Command Reference” chapter.

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 specified 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. The following table 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. The following table summarizes the FC and dot1p priority mappings based on this criteria.

For more information, see the 7705 SAR Services Guide, "Priority Mapping (802.1ag and Y.1731)".

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 is deployed 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 critical link events (defined in 802.3ah clause 57.2.10.1) are supported:

• link fault – the PHY has determined that a fault has occurred in the receive direction of the local DTE

• dying gasp – an unrecoverable local failure condition has occurred

• critical event – an unspecified critical event has occurred

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.

• All EFM OAM, including loopbacks, operate on point-to-point links only.

• EFM loopbacks are always line loopbacks (line Rx to line Tx).

• When a port is in loopback, all frames (except EFM frames) are discarded. If dynamic signaling and routing is used (dynamic LSPs, OSPF, IS-IS, or BGP routing), all services also go down. If all signaling and routing protocols are static (static routes, LSPs, and service labels), the frames are discarded but services stay up.

The following EFM OAM functions are supported:

• OAM capability discovery

• configurable transmit interval with an Information OAMPDU

• active or passive mode

• OAM loopback

• OAMPDU tunneling and termination (for Epipe service)

• dying gasp at network and access ports

For information about Epipe service, see the 7705 SAR Services Guide, "Ethernet VLL (Epipe) Services".

A line loopback loops frames received on the corresponding port back toward 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 toward 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, 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 before 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.

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, Up and Down SAP MEPs, Up and Down spoke SDP MEPs, Up and Down mesh SDP MEPs, and network interface facility 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 about CFM MEPs.

The following figure 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 (toward) 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 an SDP or SAP.

The figure shows an Ethernet verifier at the MTSO that is directly connected to the transport network (in front of the 7750 SR). Therefore, the Ethernet OAM frames are not label- encapsulated. Because 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).

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

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). Because 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".

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.

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

Label withdrawal is negotiated during the PW status negotiation phase and must 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.

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.

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:

• query arrival time

• incoming interface

• outgoing interface

• previous hop router address

• input packet count

• output packet count

• total packets for this source/group

• routing protocol

• TTL threshold

• forwarding/error code

The information enables the network administrator to determine:

• the flow of the multicast stream

• where multicast flows stop

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

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.

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. When the specified multicast router responds, the configuration is displayed.

G.826 statistics include 15-min. and 24-hr performance statistics of a radio's microwave link. These statistics include background block errors (BBE), errored seconds (ES), severely errored seconds (SES), and unavailable seconds (UAS) as specified in ITU-T Recommendation G.826.

Power level statistics include 15-min. and 24-hr performance statistics of a radio's received and transmit minimum, average, and maximum levels for over the period. The statistics are collected in units of A-weighted decibels (dBA).

The radios can automatically adjust their mode of operation based on the atmospheric conditions. A radio's adaptive coding and modulation (ACM) function use its highest modulation (256 QAM) in ideal conditions to attain the highest bandwidth possible and automatically brings down the level of modulation (and therefore bandwidth over the air) as needed in inferior atmospheric conditions.

The collected ACM statistics include 15-min. and 24-hr statistics of the time spent at each QAM level for a radio. The statistics are collected in units of milliseconds.

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. After 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. See the 7705 SAR System Management Guide, "Configuring an Accounting Policy" section for information about creating accounting files and writing to them.