3.1.1. LSP diagnostics: LSP ping and trace

Note: P2MP LSP references in this section apply only to the 7210 SAS-Mxp, 7210 SAS-R6, 7210 SAS-R12, 7210 SAS-Sx/S 1/10GE (standalone and standalone-VC mode), and 7210 SAS-T.

This section provides a generalized description of the LSP diagnostics tools. Users should take into account the following restrictions when reading the information contained in this section:

Note: 7210 SAS platforms do not support the use of ECMP routes for BGP 3107 labeled routes. The feature description is provided in this section for completeness and better understanding of the behavior in the end-to-end network solution deployed using 7210 SAS and 7750 nodes.

The router LSP diagnostics are implementations of LSP ping and LSP trace based on RFC 4379, Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures. LSP ping provides a mechanism to detect data plane failures in MPLS LSPs. LSP ping and LSP trace are modeled after the ICMP echo request/reply used by ping and trace to detect and localize faults in IP networks.

For a specific LDP FEC, RSVP P2P LSP, or BGP IPv4 Label Router, LSP ping verifies whether the packet reaches the egress label edge router (LER), while in LSP trace mode, the packet is sent to the control plane of each transit label switched router (LSR) which performs various checks to see if it is actually a transit LSR for the path.

The downstream mapping TLV is used in LSP ping and LSP trace to provide a mechanism for the sender and responder nodes to exchange and validate interface and label stack information for each downstream of an LDP FEC or an RSVP LSP and at each hop in the path of the LDP FEC or RSVP LSP.

Two downstream mapping TLVs are supported: the original Downstream Mapping (DSMAP) TLV defined in RFC 4379 and the new Downstream Detailed Mapping (DDMAP) TLV defined in RFC 6424.

When the responder node has multiple equal cost next-hops for an LDP FEC prefix, the downstream mapping TLV can further be used to exercise a specific path of the ECMP set using the path-destination option. The behavior in this case is described in the following ECMP subsection.

3.1.1.1. LSP ping/trace for an LSP using a BGP IPv4 label route

This feature adds support of the target FEC stack TLV of type BGP Labeled IPv4 /32 Prefix as defined in RFC 4379.

The new TLV is structured as shown in the following figure.

Figure 7:  Target FEC stack TLV for a BGP labeled IPv4 prefix 

The user issues a LSP ping using the existing CLI command and specifying a new type of prefix:

oam lsp-ping bgp-label prefix ip-prefix/mask [src-ip-address ip-address] [fc fc-name] [size octets] [ttl label-ttl] [send-count send-count] [timeout timeout] [interval interval] [path-destination ip-address [interface if-name | next-hop ip-address]] [detail]

The path-destination option is used for exercising specific ECMP paths in the network when the LSR performs hashing on the MPLS packet.

Similarly, the user issues a LSP trace using the following command:

oam lsp-trace bgp-label prefix ip-prefix/mask [src-ip-address ip-address] [fc fc-name] [max-fail no-response-count] [probe-count probes-per-hop] [size octets] [min-ttl min-label-ttl] [max-ttl max-label-ttl] [timeout timeout] [interval interval] [path-destination ip-address [interface if-name | next-hop ip-address]] [detail]

The following are the procedures for sending and responding to an LSP ping or LSP trace packet. These procedures are valid when the downstream mapping is set to the DSMAP TLV. The detailed procedures with the DDMAP TLV are presented in Using DDMAP TLV in LSP stitching and LSP hierarchy:

1. The next-hop of a BGP label route for a core IPv4 /32 prefix is always resolved to an LDP FEC or an RSVP LSP. Therefore, the sender node encapsulates the packet of the echo request message with a label stack which consists of the LDP/RSVP outer label and the BGP inner label.
   If the packet expires on an RSVP or LDP LSR node which does not have context for the BGP label IPv4 /32 prefix, it validates the outer label in the stack and if the validation is successful it replies the same way as it does today when it receives an echo request message for an LDP FEC which is stitched to a BGP IPv4 label route. That is, it replies with return code 8 “Label switched at stack-depth <RSC>.”
2. The LSR node that is the next-hop for the BGP label IPv4 /32 prefix as well as the LER node that originated the BGP label IPv4 prefix both have full context for the BGP IPv4 target FEC stack and, as a result, can perform full validation of it.
3. If the BGP IPv4 label route is stitched to an LDP FEC, the egress LER for the resulting LDP FEC will not have context for the BGP IPv4 target FEC stack in the echo request message and replies with return code 4 “Replying router has no mapping for the FEC at stack- depth <RSC>.” This is the same behavior as that of an LDP FEC which is stitched to a BGP IPv4 label route when the echo request message reaches the egress LER for the BGP prefix.

Note: Only BGP label IPv4 /32 prefixes are supported because these are usable as tunnels on nodes. BGP label IPv6 /128 prefixes are not currently usable as tunnels on a node and are not supported in LSP ping or trace.

3.1.1.2. ECMP considerations

Note: BGP 3107 labelled route ECMP is not supported on 7210 SAS platforms. References to BGP 3107 labelled route ECMP are included in this section only for completeness of the feature description.

When the responder node has multiple equal cost next-hops for an LDP FEC or a BGP label IPv4 prefix, it replies in the DSMAP TLV with the downstream information of the outgoing interface that is part of the ECMP next-hop set for the prefix.

However, when a BGP label route is resolved to an LDP FEC (of the BGP next-hop of the BGP label route), ECMP can exist at both the BGP and LDP levels. The following next-hop selection is performed in this case:

1. For each BGP ECMP next hop of the label route, a single LDP next hop is selected even if multiple LDP ECMP next hops exist. Therefore, the number of ECMP next hops for the BGP IPv4 label route is equal to the number of BGP next-hops.
2. ECMP for a BGP IPv4 label route is only supported at the provider edge (PE) router (BGP label push operation) and not at ABR and ASBR (BGP label swap operation). Therefore, at an LSR, a BGP IPv4 label route is resolved to a single BGP next hop, which is resolved to a single LDP next hop.
3. LSP trace will return one downstream mapping TLV for each next-hop of the BGP IPv4 label route. It will also return the exact LDP next-hop that the datapath programmed for each BGP next-hop.

In the following description of LSP ping and LSP trace behavior, generic references are made to specific terms as follows: FEC can represent either an LDP FEC or a BGP IPv4 label router, and a Downstream Mapping TLV can represent either the DSMAP TLV or the DDMAP TLV:

1. If the user initiates an LSP trace of the FEC without the path-destination option specified, the sender node does not include multi-path information in the Downstream Mapping TLV in the echo request message (multipath type=0). In this case, the responder node replies with a Downstream Mapping TLV for each outgoing interface that is part of the ECMP next-hop set for the FEC. The sender node will select the first Downstream Mapping TLV only for the subsequent echo request message with incrementing TTL.
2. If the user initiates an LSP ping of the FEC with the path-destination option specified, the sender does not include the Downstream Mapping TLV. However, the user can configure the interface option, part of the same path-destination option, to direct the echo request message at the sender node to be sent from a specific outgoing interface that is part of an ECMP path set for the FEC.
3. If the user initiates an LSP trace of the FEC with the path-destination option specified but configured to exclude a Downstream Mapping TLV in the MPLS echo request message using the CLI command downstream-map-tlv {none}, the sender node does not include the Downstream Mapping TLV. However, the user can configure the interface option, part of the same path-destination option, to direct the echo request message at the sender node to be sent out a specific outgoing interface that is part of an ECMP path set for the FEC.
4. If the user initiates an LSP trace of the FEC with the path-destination option specified, the sender node includes the multipath information in the Downstream Mapping TLV in the echo request message (multipath type=8). The path-destination option allows the user to exercise a specific path of a FEC in the presence of ECMP. The user enters a specific address from the 127/8 range, which is then inserted in the multipath type 8 information field of the Downstream Mapping TLV. The CPM code at each LSR in the path of the target FEC runs the same hash routine as the datapath and replies in the Downstream Mapping TLV with the specific outgoing interface the packet would have been forwarded to if it had not expired at this node and if the DEST IP field in the packet’s header was set to the 127/8 address value inserted in the multipath type 8 information.
5. The ldp-treetrace tool always uses the multipath type=8 value and inserts a range of 127/8 addresses instead of a single address to exercise multiple ECMP paths of an LDP FEC. The behavior is the same as the lsp-trace command with the path-destination option enabled.
6. The path-destination option can also be used to exercise a specific ECMP path of an LDP FEC tunneled over an RSVP LSP or ECMP path of an LDP FEC stitched to a BGP FEC in the presence of BGP ECMP paths. The user must enable the use of the DDMAP TLV either globally (config>test-oam>mpls-echo-request-downstream-map ddmap) or within the specific ldp-treetrace or LSP trace test (downstream-map-tlv ddmap option).

3.1.1.4. Downstream Detailed Mapping (DDMAP) TLV

The DDMAP TLV provides with exactly the same features as the existing DSMAP TLV, plus the enhancements to trace the details of LSP stitching and LSP hierarchy. The latter is achieved using a new sub-TLV of the DDMAP TLV called the FEC stack change sub-TLV. Figure 8 and Figure 9 show the structures of these two objects as defined in RFC 6424.

Figure 8:  DDMAP TLV 

The DDMAP TLV format is derived from the DSMAP TLV format. The key change is that variable length and optional fields have been converted into sub-TLVs. The fields have the same use and meaning as in RFC 4379.

Figure 9:  FEC stack change sub-TLV 

The operation type specifies the action associated with the FEC stack change. The following operation types are defined.

        Type #     Operation

        ------     ---------

        1          Push

        2          Pop

More details on the processing of the fields of the FEC stack change sub-TLV are provided later in this section.

The user can configure which downstream mapping TLV to use globally on a system by using the following command:

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

This command specifies which format of the downstream mapping TLV to use in all LSP trace packets and LDP tree trace packets originated on this node. The Downstream Mapping (DSMAP) TLV is the original format in RFC 4379 and is the default value. The Downstream Detailed Mapping (DDMAP) TLV is the new enhanced format specified in RFC 6424.

This command applies to LSP trace of an RSVP P2P LSP, a MPLS-TP LSP, a BGP IPv4 Label Route, or LDP unicast FEC, and to LDP tree trace of a unicast LDP FEC. It does not apply to LSP trace of an RSVP P2MP LSP which always uses the DDMAP TLV.

The global DSMAP/DDMAP setting impacts the behavior of both OAM LSP trace packets and SAA test packets of type lsp-trace and is used by the sender node when one of the following events occurs:

1. An SAA test of type lsp-trace is created (not modified) and no value is specified for the per-test downstream-map-tlv {dsmap | ddmap | none} option. In this case the SAA test downstream-map-tlv value defaults to the global mpls-echo-request-downstream-map value.
2. An OAM test of type lsp-trace test is executed and no value is specified for the per-test downstream-map-tlv {dsmap | ddmap | none} option. In this case, the OAM test downstream-map-tlv value defaults to the global mpls-echo-request-downstream-map value.

A consequence of the preceding rules is that a change to the value of mpls-echo-request-downstream-map option does not affect the value inserted in the downstream mapping TLV of existing tests.

The following are the details of the processing of the new DDMAP TLV:

1. When either the DSMAP TLV or the DDMAP TLV is received in an echo request message, the responder node will include 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 Downstream Mapping TLV (DSMAP or DDMAP) expires at a node which 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 a 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 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 a LSP ping from a sender node with a ttl value lower than the number of hops 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. The behavior in (a) is changed when the global configuration or the per-test setting of the Downstream Mapping TLV is set to DDMAP. The sender node will include in this case 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.

3.1.1.5. Using DDMAP TLV in LSP stitching and LSP hierarchy

In addition to performing the same features as the DSMAP TLV, the new DDMAP TLV addresses the following scenarios:

1. Full validation of an LDP FEC stitched to a BGP IPv4 label route. In this case, the LSP trace message is inserted from the LDP LSP segment or from the stitching point.
2. Full validation of a BGP IPv4 label route stitched to an LDP FEC. The LSP trace message is inserted from the BGP LSP segment or from the stitching point.
3. Full validation of an LDP FEC which is stitched to a BGP LSP and stitched back into an LDP FEC. In this case, the LSP trace message is inserted from the LDP segments or from the stitching points.
4. Full validation of an LDP FEC tunneled over an RSVP LSP using LSP trace.
5. Full validation of a BGP IPv4 label route tunneled over an RSVP LSP or an LDP FEC.

To correctly check a target FEC which is stitched to another FEC (stitching FEC) of the same or a different type, or which is tunneled over another FEC (tunneling FEC), it is necessary for the responding nodes to provide details about the FEC manipulation back to the sender node. This is achieved via the use of the new FEC stack change sub-TLV in the Downstream Detailed Mapping TLV (DDMAP) defined in RFC 6424.

When the user configures the use of the DDMAP TLV on a trace for an LSP 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.

This feature however introduces changes to the target FEC stack validation procedures at the sender and responder nodes in the case of LSP stitching and LSP hierarchy. These changes pertain to the processing of the new FEC stack change sub-TLV in the new DDMAP TLV and the new return code 15 Label switched with FEC change. The following is a description of the main changes which are a superset of the rules described in Section 4 of RFC 6424 to allow greater scope of interoperability with other vendor implementations.

3.1.1.5.1. Responder node procedures

The following are responder node procedures:

1. As a responder node, the node will always insert a global return code return code of either
   3 Replying router is an egress for the FEC at stack-depth <RSC> or
   14 See DDMAP TLV for Return Code and Return Subcode.
2. When the responder node inserts a global return code of 3, it will not include a DDMAP TLV.
3. When the responder node includes the DDMAP TLV, it inserts a global return code 14 See DDMAP TLV for Return Code and Return Subcode and:
   1. On a success response, include a return code of 15 in the DDMAP TLV for each downstream which has a FEC stack change TLV.
   2. On a success response, include a return code 8 Label switched at stack-depth <RSC> in the DDMAP TLV for each downstream 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.
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. It will therefore include two or more FEC stack change sub-TLVs in the DDMAP TLV in the echo reply message. It also includes and 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 in a sense that at 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 described in (5) as follows. The responder node will therefore perform exactly the same operation as described in this step 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).

3.1.1.5.2. Sender node procedures

The following are 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. That is, one FEC is popped at most and one or more FECs are 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 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. Note this step will continue 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 and in which case step (a) is performed. A responder node will cause 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 must ignore it and processing is performed as per steps (a) or (b) preceding. A responder node will not cause this case to occur but a third party implementation may do.
3. As a sender node, the can accept an echo-reply message with the global return code of either 14 (with DDMAP TLV return code of 15 or 8), or15 and process correctly 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 therefore the responder node, which is the egress node, will still reply with return code 4 Replying router has no mapping for the FEC at stack- depth <RSC>. This case cannot be resolved with this feature.

Note: The following limitation applies when a BGP IPv4 label route is resolved to an LDP FEC which is resolved to an RSVP LSP all on the same node. This 2-level LSP hierarchy is not supported as a feature on SR OS but the user is not prevented from configuring it. In that case, user and OAM packets are forwarded by the sender node using two labels (T-LDP and BGP). The LSP trace will fail on the downstream node with return code 1 Malformed echo request received because there is no label entry for the RSVP label.

3.1.2. MPLS OAM support in segment routing

Note: This feature is supported only on the 7210 SAS-Mxp, 7210 SAS-R6 (IMM-b and IMM-c only), 7210 SAS-R12 (IMM-b and IMM-c only), and 7210 SAS-Sx/S 1/10GE (standalone mode).

MPLS OAM supports segment routing extensions to lsp-ping and lsp-trace as defined in draft-ietf-mpls-spring-lsp-ping.

When the data plane uses MPLS encapsulation, MPLS OAM tools such as lsp-ping and lsp-trace can be used to check connectivity and trace the path to any midpoint or endpoint of an SR-ISIS or SR-OSPF shortest path tunnel.

The CLI options for lsp-ping and lsp-trace are under OAM and SAA for SR-ISIS and SR-OSPF node SID tunnels.

3.1.2.1. SR extensions for LSP-PING and LSP-TRACE

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

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

The following figure shows the format of the IPv4 IGP-prefix segment ID.

Figure 10:  IPv4 IGP-prefix SID format 

In this format, the fields are as follows:

1. IPv4 prefix
   The IPv4 Prefix field carries the IPv4 prefix to which the segment ID is assigned. For an anycast segment ID, this field carries the IPv4 anycast address. If the prefix is shorter than 32 bits, trailing bits must be set to zero.
2. Prefix length
   The Prefix Length field is one octet. It gives the length of the prefix in bits; allowed values are 1 to 32.
3. Protocol
   The Protocol field is set to 1 if the IGP protocol is OSPF and 2 if the IGP protocol is IS-IS.

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

1. SR-ISIS or SR-OSPF shortest path IPv4 tunnel
2. SR-ISIS IPv4 tunnel stitched to an LDP IPv4 FEC
3. BGP IPv4 LSP resolved over an SR-ISIS IPv4 tunnel or an SR-OSPF IPv4 tunnel; including support for BGP LSP across AS boundaries and for ECMP next-hops at the transport tunnel level

3.1.2.2. Operating guidelines on SR-ISIS or SR-OSPF tunnels

The following operating guidelines apply to lsp-ping and lsp-trace:

1. The sender node builds the target FEC stack TLV with a single FEC element corresponding to the destination node SID of the SR-ISIS or SR-OSPF tunnel.
2. A node SID label swapped at the LSR results in return code 8, “Label switched at stack-depth <RSC>” in accordance with RFC 4379.
3. A node SID label that is popped at the LSR results in return code 3, “Replying router is an egress for the FEC at stack-depth <RSC>”.
4. The lsp-trace command is supported with the inclusion of the DSMAP TLV, the DDMAP TLV, or none. If none is configured, 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 a sample topology for an lsp-ping and lsp-trace for SR-ISIS node SID tunnels.

Figure 11:  Testing MPLS OAM with SR tunnels 

Given this topology, the following output is an example of LSP-PING on DUT-A for target node SID on 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=3.2ms rc=3 (EgressRtr)

---- LSP 10.20.1.6/32 PING Statistics ----

1 packets sent, 1 packets received, 0.00% packet loss

round-trip min = 3.2ms, avg = 3.2ms, max = 3.2ms, stddev = 0.000ms

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

*A:Dut-A# oam lsp-trace sr-isis prefix 10.20.1.6/32 igp-instance 0 detail

lsp-trace to 10.20.1.6/32: 0 hops min, 0 hops max, 108 byte packets

1  10.20.1.2  rtt=2.29ms 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=3.74ms 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=4.97ms rc=3(EgressRtr) rsc=1

The following output is an example of LSP-TRACE on DUT-A for target node SID onDUT-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=2.56ms 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=3.59ms 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=5.00ms rc=3(EgressRtr) rsc=1

3.1.2.4. Operation on a BGP IPv4 LSP resolved over an SR-ISIS IPv4 tunnel or an SR-OSPF IPv4 tunnel

The 7210 SAS enhances lsp-ping and lsp-trace of a BGP IPv4 LSP resolved over an SR-ISIS IPv4 tunnel or an SR-OSPF IPv4 tunnel. The 7210 SAS enhancement reports the full set of ECMP next-hops for the transport tunnel at both ingress PE and at the ABR or ASBR. The list of downstream next-hops is reported in the DSMAP or DDMAP TLV.

If an lsp-trace of the BGP IPv4 LSP is initiated with the path-destination option specified, the CPM hash code at the responder node selects the outgoing interface to return in the DSMAP or DDMAP TLV. The decision is based on the modulo operation of the hash value on the label stack or the IP headers (where the DST IP is replaced by the specific 127/8 prefix address in the multipath type 8 field of the DSMAP or DDMAP) of the echo request message and the number of outgoing interfaces in the ECMP set.

The following figure shows a sample topology used in the subsequent BGP over SR-OSPF and BGP over SR-ISIS examples.

Figure 12:  Sample topology for BGP over SR-OSPF and SR-ISIS 

The following outputs are examples of the lsp-trace command for a hierarchical tunnel consisting of a BGP IPv4 LSP resolved over an SR-ISIS IPv4 tunnel or an SR-OSPF IPv4 tunnel.

The following output is an example of BGP over SR-OSPF.

*A:Dut-A# oam lsp-trace bgp-label prefix 10.21.1.6/32 detail downstream-map-

tlv ddmap path-destination 127.1.1. 

lsp-trace to 10.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]=262137 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# 

The following output is an example of BGP over SR-ISIS.

A:Dut-A# oam lsp-trace bgp-label prefix 10.21.1.6/32 detail downstream-map-

tlv ddmap path-destination 127.1.1.1 

lsp-trace to 10.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 

Assuming the topology in the following figure includes an eBGP peering between nodes B and C, the BGP IPv4 LSP spans the AS boundary and resolves to an SR-ISIS tunnel within each AS.

Figure 13:  Sample topology for BGP over SR-ISIS in inter-AS option C  

The following output is an example of BGP over SR-ISIS using inter-AS option C.

*A:Dut-A# oam lsp-trace bgp-label prefix 10.20.1.6/32 src-ip-

address 10.20.1.1 detail downstream-map-tlv ddmap path-destination 127.1.1.1 

lsp-trace to 10.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.1

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

3.1.3. LSP ping for RSVP P2MP LSP

Note: RSVP-based signaling for P2MP LSPs is only supported on the 7210 SAS-Mxp, 7210 SAS-R6, 7210 SAS-R12, 7210 SAS-Sx/S 1/10GE (standalone and standalone-VC mode), and 7210 SAS-T. P2MP LSP is only supported on the 7210 SAS-Mxp, 7210 SAS-R6, 7210 SAS-R12, 7210 SAS-Sx/S 1/10GE (standalone and standalone-VC mode), and 7210 SAS-T.

Enter the following OAM command to generate an LSP ping:

oam p2mp-lsp-ping lsp-name [p2mp-instance instance-name [s2l-dest-addr ip-address [...up to 5 max]]] [fc fc-name] [size octets] [ttl label-ttl] [timeout timeout] [detail]

An echo request message is sent on the active P2MP instance and replicated in the datapath over all branches of the P2MP LSP instance. By default, all egress LER nodes that are leaves of the P2MP LSP instance reply to the echo request message.

To reduce the scope of the echo reply message, explicitly enter a list of addresses specifying the egress LER nodes that must reply. A maximum of five addresses can be specified in a single execution of the p2mp-lsp-ping command. If all five egress LER nodes are router nodes, they will parse the list of egress LER addresses and reply. In accordance with RFC 6425, only the top address in the P2MP egress identifier TLV is inspected by an egress LER. When interoperating with other implementations, the egress LER router node responds if its address is in the list. Also, if another vendor implementation is the egress LER, only the egress LER matching the top address in the TLV responds.

If the user enters the same egress LER address more than once in a single p2mp-lsp-ping command, the head-end node displays a response to a single address and displays a single error warning message for the duplicates. When queried over SNMP, the head-end node issues a single response trap and issues no trap for the duplicates.

Set the value of the timeout parameter to the time it would take to get a response from all probed leaves under no failure conditions. For that purpose, the parameter range extends to 120 seconds for a p2mp-lsp-ping from a 10-second lsp-ping for P2P LSP. The default value is 10 seconds.

If the user explicitly lists the address of the egress LER for a specific S2L in the ping command, the router head-end node displays a “Send_Fail” error when a specific S2L path is down.

Similarly, if the user explicitly lists the address of the egress LER for a specific S2L in the ping command, the router head-end node displays the timeout error when no response is received for an S2L after the expiry of the timeout timer.

Configure a specific value of the ttl parameter to force the echo request message to expire on a router branch node or a bud LSR node. The bud LSR node replies with a downstream mapping TLV for each branch of the P2MP LSP in the echo reply message. A maximum of 16 downstream mapping TLVs can be included in a single echo reply message. The multipath type is set to zero in each downstream mapping TLV and, consequently, does not include egress address information for the reachable egress LER nodes for this P2MP LSP.

If the router ingress LER node receives the new multipath type field with the list of egress LER addresses in an echo reply message from another vendor implementation, the router ignores the message, but this does not cause a processing error for the downstream mapping TLV.

If the ping command expires at an LSR node that is performing a remerge or crossover operation in the datapath between two or more ILMs of the same P2MP LSP, an echo reply message is generated for each copy of the echo request message received by this node.

If the detail parameter is omitted, the command output provides a high-level summary of error and success codes received.

If the detail parameter is specified, the command output displays a line for each replying node, similar to the output of the LSP ping for a P2P LSP.

The display is delayed until all responses are received or the timer configured in the timeout parameter expires. Entering other CLI commands while waiting for the display is not allowed. Use control-C (^C) to stop the ping operation.

3.1.4. LSP trace for RSVP P2MP LSP

Note: RSVP-based signaling for P2MP LSPs is only supported on the 7210 SAS-Mxp, 7210 SAS-R6, 7210 SAS-R12, 7210 SAS-Sx/S 1/10GE (standalone and standalone-VC mode), and 7210 SAS-T. P2MP LSP is only supported on the 7210 SAS-Mxp, 7210 SAS-R6, 7210 SAS-R12, 7210 SAS-Sx/S 1/10GE (standalone and standalone-VC mode), and 7210 SAS-T.

Generate an LSP trace by entering the following OAM command:

oam p2mp-lsp-trace lsp-name p2mp-instance instance-name s2l-dest-addr ip-address [fc fc-name] [size octets] [max-fail no-response-count] [probe-count probes-per-hop] [min-ttl min-label-ttl]] [max-ttl max-label-ttl] [timeout timeout] [interval interval] [detail]

The LSP trace capability allows the user to trace the path of a single S2L path of a P2MP LSP. Its operation is similar to that of the p2mp-lsp-ping command but the sender of the echo reply request message includes the downstream mapping TLV to request the downstream branch information from a branch LSR or bud LSR. The branch LSR or bud LSR will then also include the downstream mapping TLV to report the information about the downstream branches of the P2MP LSP. An egress LER does not include this TLV in the echo response message.

The operation of the probe-count parameter is modeled after the LSP trace on a P2P LSP. It represents the maximum number of probes sent per TTL value before the device gives up on receiving the echo reply message. If a response is received from the traced node before reaching the maximum number of probes, no additional probes are sent for that TTL. The sender of the echo request increments the TTL and uses the information received in the downstream mapping TLV to send probes to the node downstream of the last node that replied. This continues until the egress LER for the traced S2L path replies.

Because the command traces a single S2L path, the timeout and interval parameters keep the same value range as the LSP trace for a P2P LSP.

The following supported options in lsp-trace for P2P LSP are not applicable: path, prefix, path-destination, and [interface | next-hop].

The P2MP LSP trace uses the Downstream Detailed Mapping (DDMAP) TLV defined in RFC 6424. The following figure shows the format of the new DDMAP TLV entered in the path-destination that belongs to one of the possible outgoing interfaces of the FEC.

Figure 14:  DDMAP TLV 

The DDMAP TLV format is derived from the Downstream Mapping (DSMAP) TLV format. The key change is that in the DDMAP TLV, the variable length and optional fields are converted into sub-TLVs. The fields have the same use and meaning as in RFC 4379.

Similar to P2MP LSP ping, an LSP trace probe results on all egress LER nodes that eventually receive the echo request message, but only the traced egress LER node replies to the last probe.

Any branch LSR node or bud LSR node in the P2MP LSP tree may receive a copy of the echo request message with the TTL in the outer label expiring at this node. However, only a branch LSR or bud LSR that has a downstream branch over which the traced egress LER is reachable must respond.

When a branch LSR or BUD LSR node responds to the sender of the echo request message, it sets the global return code in the echo response message to RC=14, “See DDMAP TLV for Return Code and Return Sub-Code” and the return code in the DDMAP TLV corresponding to the outgoing interface of the branch used by the traced S2L path to RC=8, “Label switched at stack-depth <RSC>”.

Because a single egress LER address, for example an S2L path, can be traced, the branch LSR or bud LSR node sets the multipath type to zero in the downstream mapping TLV in the echo response message because including an egress LER address is not required.

3.1.4.1. LSP trace behavior when S2L path traverses a re-merge node

Note: P2MP LSPs are supported only on the 7210 SAS-Mxp, 7210 SAS-R6, 7210 SAS-R12, 7210 SAS-Sx/S 1/10GE (standalone and standalone-VC mode), and 7210 SAS-T.

When a node performs a re-merge of one or more ILMs of the P2MP LSP to which the traced S2L sub-LSP belongs, it may block the ILM over which the traced S2L resides. This causes the trace to either fail or to succeed with a missing hop.

The following is an example of this behavior:

S2L1 and S2L2 use ILMs that re-merge at node B. Depending of which ILM is blocked at B, the TTL=2 probe will either yield two responses or timeout.

S2L1 = ACBDF (to leaf F)

S2L2 = ABDE (to leaf E)

 

   A

 /  \

B -- C

|  

D

| \

F  E

1. Tracing S2L1 when ILM on interface C-B blocked at node B:
   1. For TTL=1, A gets a response from C only as B does not have S2L1 on the ILM on interface A-B.
   2. For TTL=2, assume A gets first the response from B which indicates a success. It then builds the next probe with TTL=3. B will only pass the copy of the message arriving on interface A-B and will drop the one arriving on interface C-B (treats it like a data packet since it does not expire at node B). This copy will expire at F. However F will return a "DSMappingMismatched" error because the DDMAP TLV was the one provided by node B in TTL=2 step. The trace will abort at this point in time. However, A knows it got a second response from Node D for TTL=2 with a "DSMappingMismatched" error.
   3. If A gets the response from D first with the error code, it waits to see if it gets a response from B or it times out. In either case, it will log this status as multiple replies received per probe in the last probe history and aborts the trace.
2. Tracing S2L2 when ILM on interface A-B blocked at node B:
   1. For TTL=1, B responds with a success. C does not respond as it does not have an ILM for S2L2.
   2. For TTL=2, B drops the copy coming on interface A-B. It receives a copy coming on interface B-C but will drop it as the ILM does not contain S2L2. Node A times out. Next, node A generates a probe with TTL=3 without a DDMAP TLV. This time node D will respond with a success and will include its downstream DDMAP TLV to node E. The rest of the path will be discovered correctly. The traced path for S2L2 will look something like: A-B-(*)-D-E.

The router ingress LER detects a re-merge condition when it receives two or more replies to the same probe, such as the same TTL value. It displays the following message to the user regardless if the trace operation successfully reached the egress LER or was aborted earlier:

Probe returned multiple responses. Result may be inconsistent.

This warning message indicates to the user the potential of a re-merge scenario and that a p2mp-lsp-ping command for this S2L should be used to verify that the S2L path is not defective.

The router ingress LER behavior is to always proceed to the next ttl probe when it receives an OK response to a probe or when it times out on a probe. If however it receives replies with an error return code, it must wait until it receives an OK response or it times out. If it times out without receiving an OK reply, the LSP trace must be aborted.

The following are possible echo reply messages received and corresponding ingress LER behavior:

1. One or more error return codes + OK: display OK return code. Proceed to next ttl probe. Display warning message at end of trace.
2. OK + One or more error return codes: display OK return code. Proceed to next ttl probe right after receiving the OK reply but keep state that more replies received. Display warning message at end of trace.
3. OK + OK: should not happen for re-merge but would continue trace on 1st OK reply. This is the case when one of the branches of the P2MP LSP is activating the P2P bypass LSP. In this case, the head-end node will get a reply from both a regular P2MP LSR which has the ILM for the traced S2L and from an LSR switching the P2P bypass for other S2Ls. The latter does not have context for the P2MP LSP being tunneled but will respond after doing a label stack validation.
4. One error return code + timeout: abort LSP trace and display error code. Ingress LER cannot tell the error is due to a re-merge condition.
5. More than one error return code + timeout: abort LSP trace and display first error code. Display warning message at end of trace.
6. Timeout on probe without any reply: display “*” and proceed to next ttl probe.

3.1.5. SDP diagnostics

The 7210 SAS SDP diagnostics are SDP ping and SDP MTU path discovery.

3.1.6. Service diagnostics

-The Nokia Service ping feature provides end-to-end connectivity testing for an individual service. Service ping operates at a higher level than the SDP diagnostics in that it verifies an individual service and not the collection of services carried within an SDP.

Service ping is initiated from a 7210 SAS router to verify round-trip connectivity and delay to the far-end of the service. -The Nokia implementation functions for MPLS tunnels and tests the following from edge-to-edge:

3.1.7. VPLS MAC diagnostics

While the LSP ping, SDP ping and service ping tools enable transport tunnel testing and verify whether the correct transport tunnel is used, they do not provide the means to test the learning and forwarding functions on a per-VPLS-service basis.

It is conceivable, that while tunnels are operational and correctly bound to a service, an incorrect Forwarding Information Base (FIB) table for a service could cause connectivity issues in the service and not be detected by the ping tools. Nokia has developed VPLS OAM functionality to specifically test all the critical functions on a per-service basis. These tools are based primarily on the IETF document draft-stokes-vkompella-ppvpn-hvpls-oam-xx.txt, Testing Hierarchical Virtual Private LAN Services.

The VPLS OAM tools are:

3.1.8. VLL diagnostics

3.1.8.1. VCCV ping

VCCV ping is used to check connectivity of a VLL in-band. It checks that the destination (target) PE is the egress 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 SDP.

3.1.8.1.1. VCCV-ping application

VCCV effectively creates an IP control channel within the pseudowire between PE1 and PE2. PE2 should be able to distinguish on the receive side VCCV control messages from user packets on that VLL. There are three possible methods of encapsulating a VCCV message in a VLL which translates into three types of control channels:

1. Use of a Router Alert Label immediately preceding the VC label. This method has the drawback that if ECMP is applied to the outer LSP label (for example, 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 7210 SAS.
2. Use of the OAM control word as illustrated in the following figure.

   Figure 15:  OAM control word format 

   
   The first nibble is set to 0x1. The Format ID and the reserved fields are set to 0 and the channel type is the code point associated with the VCCV IP control channel as specified in the PWE3 IANA registry (RFC 4446). The channel type value of 0x21 indicates that the Associated Channel carries an IPv4 packet.
   The use of the OAM control word assumes that the draft-martini control word is also used on the user packets. This means that if the control word is optional for a VLL and is not configured, the PE node will only advertise the router alert label as the CC capability in the Label Mapping message. This method is supported on 7210 SAS configured in the network mode of operation.
3. Set the TTL in the VC label to 1 to force PE2 control plane to process the VCCV message. This method is not guaranteed to work under all circumstances. For instance, the draft mentions some implementations of penultimate hop popping overwrite the TTL field. This method is not supported on the 7210 SAS.

When sending the label mapping message for the VLL, PE1 and PE2 must indicate which of the preceding OAM packet encapsulation methods (for example, which control channel type) they support. This is accomplished by including an optional VCCV TLV in the pseudowire FEC Interface Parameter field. The following figure shows the format of the VCCV TLV.

Figure 16:  VCCV TLV format 

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

The Control Channel (CC) Type field is a bitmask used to indicate if the PE supports none, one, or many control channel types, as follows:

1. 0x00 None of the following VCCV control channel types are supported
2. 0x01 PWE3 OAM control word (see Figure 15)
3. 0x02 MPLS Router Alert Label
4. 0x04 MPLS inner label TTL = 1

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

The Connectivity Verification (CV) bitmask field is used to indicate the specific type of VCCV packets to be sent over the VCCV control channel. The valid values are:

0x00 None of the following VCCV packet type are supported.

0x01 ICMP ping. Not applicable to a VLL over a MPLS SDP and as such is not supported by the 7210 SAS.

0x02 LSP ping. This is used in VCCV-Ping application and applies to a VLL over an MPLS SDP. This is supported by the 7210 SAS.

A VCCV ping is an LSP echo request message as defined in RFC 4379. It contains an L2 FEC stack TLV which must include within the sub-TLV type 10 “FEC 128 Pseudowire”. It also contains a field which indicates to the destination PE which reply mode to use. There are four reply modes defined in RFC 4379:

Reply mode, meaning:

1. Do not reply. This mode is supported by the 7210 SAS.
2. Reply via an IPv4/IPv6 UDP packet. This mode is supported by the 7210 SAS.
3. Reply with an IPv4/IPv6 UDP packet with a router alert. This mode sets the router alert bit in the IP header and is not be confused with the CC type which makes use of the router alert label. This mode is not supported by the 7210 SAS.
4. Reply via 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 7210 SAS.

The reply is an LSP echo reply message as defined in RFC 4379. The message is sent as per the reply mode requested by PE1. The return codes supported are the same as those supported in the 7210 SAS LSP ping capability.

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

The following figure shows the VCCV-ping feature application.

Figure 17:  VCCV-ping application 

3.1.8.1.2. VCCV-ping in a multi-segment pseudowire

Pseudowire switching is a method for scaling a large network of VLL or VPLS services by removing the need for a full mesh of T-LDP sessions between the PE nodes as the number of these nodes grow over time. Pseudowire switching is also used whenever there is a need to deploy a VLL service across two separate routing domains.

In the network, a Termination PE (T-PE) is where the pseudowire originates and terminates.

VCCV ping is extended to be able to perform the following OAM functions:

1. 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 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 7210 SAS PE1 node does not process the VCCV OAM Control Word unless the VC label TTL expires. In that case, the message is sent to the CPM for further validation and processing. This is the method described in draft-hart-pwe3-segmented-pw-vccv.

3.1.9. MPLS-TP on-demand OAM commands

Note: This feature is supported only on 7210 SAS-T (network operating mode), 7210 SAS-R6, and 7210 SAS-R12.

Ping and Trace tools for PWs and LSPs are supported with both IP encapsulation and the MPLS-TP on demand CV channel for non-IP encapsulation (0x025).

3.1.10. MPLS-TP show commands

3.1.11. MPLS-TP debug commands

The following command provides the debug command for an MPLS-TP tunnel:

tools>dump>router>mpls>tp-tunnel lsp-name [clear]

The following is a sample output:

The following command shows the free MPLS tunnel IDs.

The following command provides a debug tool to view control-channel-status signaling packets.

3.2.1. Two-Way Active Measurement Protocol (TWAMP)

Two-Way Active Measurement Protocol (TWAMP) provides a standards-based method for measuring the round-trip IP performance (packet loss, delay and jitter) between two devices. TWAMP uses the methodology and architecture of One-Way Active Measurement Protocol (OWAMP) to define a way to measure two-way or round-trip metrics.

There are four logical entities in TWAMP:

The control-client and session-sender are typically implemented in one physical device (the “client”) and the server and session-reflector in a second physical device (the “server”) with which the two-way measurements are being performed. The 7210 SAS acts as the server. The control-client and server establishes a TCP connection and exchange TWAMP-Control messages over this connection. When the control-client requires to start testing, the client communicates the test parameters to the server. If the server corresponds to conduct the described tests, the test begins as soon as the client sends a Start-Sessions message. As part of a test, the session sender sends a stream of UDP-based test packets to the session-reflector, and the session reflector responds to each received packet with a response UDP-based test packet. When the session-sender receives the response packets from the session-reflector, the information is used to calculate two-way delay, packet loss, and packet delay variation between the two devices.

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

TWAMP Light is an optional model included in the TWAMP standard RFC5357 that uses standard TWAMP test packets but provides a lightweight approach to gathering ongoing IP delay performance data for base router and per-VPRN statistics. Full details are described in Appendix I of RFC 5357 (Active Two Way Measurement Protocol). The 7210 SAS implementation supports the TWAMP Light model for gathering delay and loss statistics.

For TWAMP Light, the TWAMP Client/Server model is replaced with the Session Controller/Responder model. In general terms, the Session Controller is the launch point for the test packets and the Responder performs the reflection function.

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 configuration. For example, CoS parameters communicated over the TWAMP control channel are replaced with a reply-in-kind approach. The reply-in-kind model reflects back the received CoS parameters, which are influenced by the reflector’s QoS policies.

The responder 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 the prefixes that the reflector will accept as valid sources for a TWAMP Light request. If the configured TWAMP Light listening UDP port is in use by another application on the system, a Minor OAM message will be presented indicating that the port is unavailable and that the activation of the reflector is not allowed.

f 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. An inactivity timeout under the config>oam-test>twamp>twamp-light hierarchy defines the amount of time the reflector will keep the individual reflector sessions active in the absence of test packets. A responder requires CPM3 or better hardware.

TWAMP Light test packet launching is controlled by the OAM Performance Monitoring (OAM-PM) architecture and adheres to those rules; this includes the assignment of a test Id. TWAMP Light does not carry the 4-byte test ID in the packet to remain locally significant and uniform with other protocols under the control of the OAM-PM architecture. The OAM-PM construct allow the various test parameters to be defined. These test parameters include the IP session-specific information which allocates the test to the specific routing instance, the source and destination IP address, the destination UDP port (which must match the listening UDP port on the reflector) and a number of other options that allow the operator to influence the packet handling. The probe interval and padding size can be configured under the specific session. The size of the all “0” padding can be included to ensure that the TWAMP packet is the same size in both directions. The TWAMP PDU definition does not accomplish symmetry by default. A pad size of 27 bytes will accomplish symmetrical TWAMP frame sizing in each direction.

The OAM-PM architecture does not perform any validation of the session information. The test will be allowed to be activated regardless of the validity of this information. For example, if the configured source IP address is not local within the router instance to which the test is allocated, the test will start sending TWAMP Light packets but will not receive any responses.

The OAM Performance Monitoring (OAM-PM) section of this guide provides more information describing the integration of TWAMP Light and the OAM-PM architecture, including hardware dependencies.

The following is a summary of supported TWAMP Light functions.

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

The following is a sample reflector configuration output.

The following is a sample session controller configuration output.

3.3.1. ETH-CFM building blocks

The IEEE and the ITU-T use their own nomenclature when describing administrative contexts and functions. This introduces a level of complexity to configuration, description and different vendors naming conventions. The 7210 SAS OS CLI has chosen to standardize on the IEEE 802.1ag naming where overlap exists. ITU-T naming is used when no equivalent is available in the IEEE standard. In the following definitions, both the IEEE name and ITU-T names are provided for completeness, using the format IEEE Name/ITU-T Name.

Maintenance Domain (MD)/Maintenance Entity (ME) is the administrative container that defines the scope, reach and boundary for faults. It is typically the area of ownership and management responsibility. The IEEE allows for various formats to name the domain, allowing up to 45 characters, depending on the format selected. ITU-T supports only a format of none and does not accept the IEEE naming conventions:

Maintenance Association (MA)/Maintenance Entity Group (MEG) is the construct where the different management entities will be contained. Each MA is uniquely identified by its MA-ID. The MA-ID is comprised of the by the MD level and MA name and associated format. This is another administrative context where the linkage is made between the domain and the service using the bridging-identifier configuration option. The IEEE and the ITU-T use their own specific formats. The MA short name formats (0-255) have been divided between the IEEE (0-31, 64-255) and the ITU-T (32-63), with five currently defined (1-4, 32). Even though the different standards bodies do not have specific support for the others formats a Y.1731 context can be configured using the following IEEE format options:

Note: When a VID is used as the short MA name, 802.1ag will not support VLAN translation because the MA-ID must match all the MEPs. The default format for a short MA name is an integer. Integer value 0 means the MA is not attached to a VID. This is useful for VPLS services on 7210 SAS platforms because the VID is locally significant.

Maintenance Domain Level (MD Level)/Maintenance Entity Group Level (MEG Level) is the numerical value (0-7) representing the width of the domain. The wider the domain, higher the numerical value, the farther the ETH-CFM packets can travel. It is important to understand that the level establishes the processing boundary for the packets. Strict rules control the flow of ETH-CFM packets and are used to ensure correct handling, forwarding, processing and dropping of these packets. To keep it simple ETH-CFM packets with higher numerical level values will flow through MEPs on MIPs on SAPs configured with lower level values. This allows the operator to implement different areas of responsibility and nest domains within each other. Maintenance association (MA) includes a set of MEPs, each configured with the same MA-ID and MD level used verify the integrity of a single service instance.

Maintenance Endpoint (MEP)/MEG Endpoint (MEP) are the workhorses of ETH-CFM. A MEP is the unique identification within the association (0-8191). Each MEP is uniquely identified by the MA-ID, MEPID tuple. This management entity is responsible for initiating, processing and terminating ETH-CFM functions, following the nesting rules. MEPs form the boundaries which prevent the ETH-CFM packets from flowing beyond the specific scope of responsibility. A MEP has direction, up or down. Each indicates the directions packets will be generated; UP toward the switch fabric, down toward the SAP away from the fabric. Each MEP has an active and passive side. Packets that enter the active point of the MEP will be compared to the existing level and processed accordingly. Packets that enter the passive side of the MEP are passed transparently through the MEP. Each MEP contained within the same maintenance association and with the same level (MA-ID) represents points within a single service. MEP creation on a SAP is allowed only for Ethernet ports with NULL, Q-tags, Q-in-Q encapsulations. MEPs may also be created on SDP bindings.

Maintenance Intermediate Point (MIP)/MEG Intermediate Point (MIP) are management entities between the terminating MEPs along the service path. These provide insight into the service path connecting the MEPs. MIPs only respond to Loopback Messages (LBM) and Linktrace Messages (LTM). All other CFM functions are transparent to these entities. Only one MIP is allowed per SAP or SDP. The creation of the MIPs can be done when the lower level domain is created (explicit). This is controlled by the use of the mhf-creation mode within the association under the bridge-identifier. MIP creation is supported on a SAP and SDP, not including Mesh SDP bindings. By default, no MIPs are created.

There are two locations in the configuration where ETH-CFM is defined. The domains, associations (including linkage to the service id), MIP creation method, common ETH-CFM functions and remote MEPs are defined under the top level eth-cfm command. It is important to note, when Y.1731 functions are required the context under which the MEPs are configured must follow the Y.1731 specific formats (domain format of none, MA format icc-format). When these parameters have been entered, the MEP and possibly the MIP can be defined within the service under the SAP or SDP.

Table 12, Table 13, Table 14, Table 15, Table 16, and Table 17 are general tables that indicates the ETH-CFM support for the different services and endpoints. It is not meant to indicate the services that are supported or the requirements for those services on the individual platforms.

The following figures show the detailed IEEE representation of MEPs, MIPs, levels and associations, using the standards defined icons.

Figure 18:  MEP and MIP 

Figure 19:  MEP, MIP and MD levels 

3.3.1.1. Loopback

A loopback message is generated by a MEP to its peer MEP (see the following figure). The functions are similar to an IP ping to verify Ethernet connectivity between the nodes.

Figure 20:  CFM loopback 

The following loopback-related functions are supported:

1. Loopback message functionality on a MEP or MIP can be enabled or disabled.
2. A MEP supports generating loopback messages and responding to loopback messages with loopback reply messages.
3. A MIP supports responding to loopback messages with loopback reply messages when loopback messages are targeted to itself.
4. The Sender ID TLV may optionally be configured to carry the Chassis ID. When configured, the following information will be included in LBM messages:
   1. Only the Chassis ID portion of the TLV will be included.
   2. The Management Domain and Management Address fields are not supported on transmission.
   3. As per the specification, the LBR function copies and returns any TLVs received in the LBM message. This means that the LBR message will include the original Sender ID TLV.
   4. The Sender ID TLV is supported for service (id-permission) MEPs.
   5. The Sender ID TLV is supported for both MEPs and MIPs.
5. Loopback test results are displayed on the originating MEP. There is a limit of 10 outstanding tests per node.

3.3.1.2. Linktrace

A linktrace message is originated by an MEP and targeted to a peer MEP in the same MA and within the same MD level (see Figure 21). Its function is similar to IP traceroute. Linktrace traces a specific MAC address through the service. The peer MEP responds with a linktrace reply message after successful inspection of the linktrace message. The MIPs along the path also process the linktrace message and respond with linktrace replies to the originating MEP if the received linktrace message that has a TTL greater than 1; the MIPs also forward the linktrace message if a lookup of the target MAC address in the Layer 2 FIB is successful. The originating MEP will receive multiple linktrace replies and from processing the linktrace replies, it can put together the route to the target bridge.

A traced MAC address (the targeted MAC address) is carried in the payload of the linktrace message. Each MIP and MEP receiving the linktrace message checks whether it has learned the target MAC address. To use linktrace, the target MAC address must have been learned by the nodes in the network. If the address has been learned, a linktrace message is sent back to the originating MEP. A MIP forwards the linktrace message out of the port where the target MAC address was learned.

The linktrace message has a multicast destination address. On a broadcast LAN, it can be received by multiple nodes connected to that LAN; However, only one node will send a reply.

Figure 21:  CFM linktrace 

The following linktrace-related functions are supported:

1. Linktrace functions can be enabled or disabled on an MEP.
2. A MEP supports generating linktrace messages and responding with linktrace reply messages.
3. A MIP supports responding to linktrace messages with linktrace reply messages when encoded TTL is greater than 1; The MIPs forward the linktrace messages accordingly if a lookup of the target MAC address in the Layer 2 FIB is successful.
4. The Sender ID TLV may optionally be configured to carry the Chassis ID. When configured, the following information will be included in LTM and LTR messages:
   1. Only the Chassis ID portion of the TLV will be included.
   2. The Management Domain and Management Address fields are not supported on transmission.
   3. The LBM message will include the Sender ID TLV that is configured on the launch point. The LBR message will include the Sender ID TLV information from the reflector (MIP or MEP) if it is supported.
   4. The Sender ID TLV is supported for service (id-permission) MEPs.
   5. The Sender ID TLV is supported for both MEPs and MIPs.

The display output has been updated to include the Sender ID TLV contents if they are included in the LBR.

oam eth-cfm linktrace 00:00:00:00:00:30 mep 28 domain 14 association 2

Index Ingress Mac          Egress Mac           Relay     Action

----- -------------------- -------------------- ---------- ----------

1     00:00:00:00:00:00    00:00:00:00:00:30    n/a       terminate

SenderId TLV: ChassisId (local)

              access-012-west

----- -------------------- -------------------- ---------- ----------

No more responses received in the last 6 seconds.

 

 

1. Linktrace test results are displayed on the originating MEP. There is a limit of 10 outstanding tests per node. Storage is provided for up to 10 MEPs and for the last 10 responses. If more than 10 responses are received older entries will be overwritten.

3.3.1.3. Continuity Check (CC)

A Continuity Check Message (CCM) is a multicast frame that is generated by a MEP and multicast to all other MEPs in the same MA. The CCM does not require a reply message. To identify faults, the receiving MEP maintains an internal list of remote MEPs it should be receiving CCM messages from.

This list is based on the remote MEP ID configuration within the association the MEP is created in. When the local MEP does not receive a CCM from one of the configured remote MEPs within a preconfigured period, the local MEP raises an alarm.

The following figure shows a CFM continuity check.

Figure 22:  CFM Continuity Check 

The following figure shows a CFM CC failure scenario.

Figure 23:  CFM CC failure scenario 

The following functions are supported:

1. CC can be enabled and disabled for an MEP.
2. MEP entries can be configured and deleted in the CC MEP monitoring database manually. Only remote MEPs must be configured. Local MEPs are automatically added to the database when they are created.
3. The CCM transmit interval is configurable. See the Diagnostics command reference for more information about supported timer intervals on different platforms for MEPs used in the service context and G.8032 control instance context.
4. CCM will declare a fault, when:
   1. the CCM stops hearing from one of the remote MEPs for 3.5 times CC interval
   2. the CCM hears from a MEP with a LOWER MD level
   3. the CCM hears from a MEP that is not part of the local MEP’s MA
   4. the CCM hears from a MEP that is in the same MA but not in the configured MEP list
   5. the CCM hears from a MEP that is in the same MA with the same MEP ID as the receiving MEP
   6. the CC interval of the remote MEP does not match the local configured CC interval
   7. the remote MEP is declaring a fault
5. An alarm is raised and a trap is sent if the defect is greater than or equal to the configured low-priority-defect value.
6. Remote Defect Indication (RDI) is supported but by default is not recognized as a defect condition because the low-priority-defect setting default does not include RDI.
7. The Sender ID TLV may optionally be configured to carry the Chassis ID. When configured, the following information will be included in CCM messages:
   1. Only the Chassis ID portion of the TLV will be included.
   2. The Management Domain and Management Address fields are not supported on transmission.
   3. The Sender ID TLV is not supported with subsecond CCM-enabled MEPs.
   4. The Sender ID TLV is supported for service (id-permission) MEPs.

3.3.2. Y.1731 time stamp capability

Accurate results for one-way and two-way delay measurement tests using Y.1731 messages are obtained if the nodes are capable of time stamping packets in hardware:

Note: On 7210 SAS-T, 7210 SAS-Mxp, 7210 SAS-R6, 7210 SAS-R12 after PTP is enabled once, if the user needs to go back to NTP time scale, or system free-run time scale, a node reboot is required.

3.3.3. ITU-T Y.1731 Ethernet Bandwidth Notification

Note: This feature is only supported on the 7210 SAS-Mxp, 7210 SAS-R6, and 7210 SAS-R12.

The Ethernet Bandwidth Notification (ETH-BN) function is used by a server MEP to signal link bandwidth changes to a client MEP.

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) 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 server MEP transmits periodic frames with ETH-BN information, including the interval, the nominal and currently available bandwidth. A port MEP with the ETH-BN feature enabled will process the information contained in the CFM PDU and appropriately adjust the rate of traffic sent to the radio.

A port MEP that is not a LAG member port supports the client side reception and processing of the ETH-BN CFM PDU sent by the server MEP. By default, processing is disabled. The config port ethernet eth-cfm mep eth-bn receive CLI command sets the ETH-BN processing state on the port MEP. A port MEP supports untagged packet processing of ETH-CFM PDUs at domain levels 0 and 1 only. The port client MEP sends the ETH-BN rate information received to be applied to the port egress rate in a QoS update. A pacing mechanism limits the number of QoS updates sent. The config port ethernet eth-cfm mep eth-bn rx-update-pacing CLI command allows the updates to be paced using a configurable range of 1 to 600 seconds (the default is 5 seconds). The pacing timer begins to count down following the most recent QoS update sent to the system for processing. When the timer expires, the most recent update that arrived from the server MEP is compared to the most recent value sent for system processing. If the value of the current bandwidth is different from the previously processed value, the update is sent and the process begins again. Updates with a different current bandwidth that arrive when the pacing timer has already expired are not subject to a timer delay. Refer to the 7210 SAS-Mxp, R6, R12, S, Sx, T Interface Configuration Guide for more information about these CLI commands.

A complimentary QoS configuration is required to allow the system to process current bandwidth updates from the CFM engine. The config port ethernet eth-bn-egress-rate-changes CLI command is required to enable the QoS function to update the port egress rates based on the current available bandwidth updates from the CFM engine. By default, the function is disabled.

Both the CFM and QoS functions must be enabled for the changes in current bandwidth to dynamically update the egress rate.

When the MEP enters a state that prevents it from receiving the ETH-BNM, the current bandwidth last sent for processing is cleared and the egress rate reverts to the configured rate. Under these conditions, the last update cannot be guaranteed as current. Explicit notification is required to dynamically update the port egress rate. The following types of conditions lead to ambiguity:

If the eth-bn-egress-rate-changes command is disabled using the no option, CFM continues to send updates, but the updates are held without affecting the port egress rate.

The ports supporting ETH-BN MEPs can be configured for the network, access, hybrid, and access-uplink modes. When ETH-BN is enabled on a port MEP and the config>port>ethernet>eth-cfm>mep>eth-bn>receive and the QoS config>port>ethernet>eth-bn-egress-rate-changes contexts are configured, the egress rate is dynamically changed based on the current available bandwidth indicated by the ETH-BN server.

Note: For SAPs configured on an access port or hybrid port, changes in port bandwidth on reception of ETH-BNM messages will result in changes to the port egress rate, but the SAP egress aggregate shaper rate and queue egress shaper rate provisioned by the user are unchanged, which may result in an oversubscription of the committed bandwidth. Consequently, Nokia recommends that the user should change the SAP egress aggregate shaper rate and queue egress shaper rate for all SAPs configured on the port from an external management station after egress rate changes are detected on the port.

The port egress rate is capped by the minimum of the configured egress-rate, and the maximum port rate. The minimum egress rate using ETH-BN is 1024 kb/s. If a current bandwidth of zero is received, it does not affect the egress port rate and the previously processed current bandwidth will continue to be used.

The client MEP requires explicit notification of changes to update the port egress rate. The system does not timeout any previously processed current bandwidth rates using a timeout condition. The specification does allow a timeout of the current bandwidth if a frame has not been received in 3.5 times the ETH-BNM interval. However, the implicit approach can lead to misrepresented conditions and has not been implemented.

When you start or restart the system, the configured egress rate is used until an ETH-BNM arrives on the port with a new bandwidth request from the ETH-BN server MEP.

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

The destination MAC address can be a Class 1 multicast MAC address (that is, 01-80-C2-00-0x) or the MAC address of the port MEP configured. Standard CFM validation and identification must be successful to process CFM PDUs.

For information on the eth-bn-egress-rate-changes command, refer to the 7210 SAS-Mxp, R6, R12, S, Sx, T Interface Configuration Guide.

The Bandwidth Notification Message (BNM) PDU used for ETH-BN information is a sub-OpCode within the Ethernet Generic Notification Message (ETH-GNM).

The following table shows the BNM PDU format fields.

The show eth-cfm mep eth-bandwidth-notification display output includes the ETH-BN values received and extracted from the PDU, including a last reported value and the pacing timer. If the n/a value appears in the field, it indicates that field has not been processed.

The base show eth-cfm mep output is expanded to include the disposition of the ETH-BN receive function and the configured pacing timer.

The show port port-id detail is expanded to include an Ethernet Bandwidth Notification Message Information section. This section includes the ETH-BN Egress Rate disposition and the current Egress BN rate being used.

3.3.4. Port-based MEPs

The 7210 SAS supports port-based MEPs for use with CFM ETH-BN. The port MEP must be configured at level 0 or 1 and can be used for ETH-BN message reception and processing as described in ITU-T Y.1731 Ethernet Bandwidth Notification. Port-based MEPs only support CFM CC, LT, LS, and RDI message processing; other CFM and Y.1731 messages are not supported.

Note: Port-based MEPs are designed for the ETH-BN application. Nokia does not recommend the use of port-based MEPs with other applications.

3.3.5. ETH-CFM statistics

Note: This feature is supported on all 7210 SAS platforms as described in this document, including those operating in access-uplink mode.

A number of statistics are available to view the current processing requirements for CFM. Any packet that is counted against the CFM resource is included in the statistics counters. The counters do not include sub-second CCM and ETH-CFM PDUs generated by non-ETH-CFM functions (which include OAM-PM & SAA) or filtered by a security configuration.

SAA and OAM-PM use standard CFM PDUs. The reception of these packets is included in the receive statistics. However, SAA and OAM-PM launch their own test packets and do not consume ETH-CFM transmission resources.

Per-system and per-MEP statistics are included with a per-OpCode breakdown. These statistics help operators determine the busiest active MEPs on the system and provide a breakdown of per-OpCode processing at the system and MEP level.

Use the show eth-cfm statistics command to view the statistics at the system level. Use the show eth-cfm mep mep-id domain md-index association ma-index statistics command to view the per-MEP statistics. Use the clear eth-cfm mep mep-id domain md-index association ma-index statistics command to clear statistics. The clear command clears the statistics for only the specified function. For example, clearing the system statistics does not clear the individual MEP statistics because each MEP maintains its own unique counters.

All known OpCodes are listed in the transmit and receive columns. Different versions for the same OpCode are not displayed. This does not imply that the network element supports all functions listed in the table. Unknown OpCodes are dropped.

Use the tools dump eth-cfm top-active-meps command to display the top ten active MEPs in the system. This command provides a nearly real-time view of the busiest active MEPS by displaying the active (not shutdown) MEPs and inactive (shutdown) MEPs in the system. ETH-CFM MEPs that are shutdown continue to consume CPM resources because the main task is syncing the PDUs. The counts begin from the last time that the command was issued using the clear option.

3.3.6. Synthetic Loss Measurement (ETH-SL)

Nokia applied pre-standard OpCodes 53 (Synthetic Loss Reply) and 54 (Synthetic Loss Message) for the purpose of measuring loss using synthetic packets.

Note: These will be changes to the assigned standard values in a future release. This means that the Release 4.0R6 is prestandard and will not interoperate with future releases of SLM or SLR that supports the standard OpCode values.

This synthetic loss measurement approach is a single-ended feature that allows the operator to run on-demand and proactive tests to determine “in”, “out” loss and “unacknowledged” packets. This approach can be used between peer MEPs in both point to point and multipoint services. Only remote MEP peers within the association and matching the unicast destination will respond to the SLM packet.

The specification uses various sequence numbers to determine in which direction the loss occurred. Alcatel-Lucent has implemented the required counters to determine loss in each direction. To correctly use the information that is gathered the following terms are defined:

The per probe specific loss indicators are available when looking at the on-demand test runs, or the individual probe information stored in the MIB. When tests are scheduled by Service Assurance Application (SAA) the per probe data is summarized and per probe information is not maintained. Any “unacknowledged” packets will be recorded as “in-loss” when summarized.

The on-demand function can be executed from CLI or SNMP. The on demand tests are meant to provide the carrier a way to perform on the spot testing. However, this approach is not meant as a method for storing archived data for later processing. The probe count for on demand SLM has a range of one to 100 with configurable probe spacing between one second and ten seconds. This means it is possible that a single test run can be up to 1000 seconds.

Although possible, it is more likely the majority of on demand case can increase to 100 probes or less at a one second interval. A node may only initiate and maintain a single active on demand SLM test at any specific time. A maximum of one storage entry per remote MEP is maintained in the results table. Subsequent runs to the same peer can overwrite the results for that peer. This means, when using on demand testing the test should be run and the results checked before starting another test.

The proactive measurement functions are linked to SAA. This backend provides the scheduling, storage and summarization capabilities. Scheduling may be either continuous or periodic. It also allows for the interpretation and representation of data that may enhance the specification. As an example, an optional TVL has been included to allow for the measurement of both loss and delay or jitter with a single test. The implementation does not cause any interoperability because the optional TVL is ignored by equipment that does not support this. In mixed vendor environments loss measurement continues to be tracked but delay and jitter can only report round trip times. It is important to point out that the round trip times in this mixed vendor environments include the remote nodes processing time because only two time stamps will be included in the packet. In an environment where both nodes support the optional TLV to include time stamps unidirectional and round trip times is reported. Since all four time stamps are included in the packet the round trip time in this case does not include remote node processing time. Of course, those operators that wish to run delay measurement and loss measurement at different frequencies are free to run both ETH-SL and ETH-DM functions. ETH-SL is not replacing ETH-DM. Service Assurance is only briefly described here to provide some background on the basic functionality. To know more about SAA functions see Service Assurance Agent overview.

The ETH-SL packet format contains a test-id that is internally generated and not configurable. The test-id is visible for the on demand test in the display summary. It is possible for a remote node processing the SLM frames receives overlapping test-ids as a result of multiple MEPs measuring loss between the same remote MEP. For this reason, the uniqueness of the test is based on remote MEP-ID, test-id and Source MAC of the packet.

ETH-SL is applicable to up and down MEPs and as per the recommendation transparent to MIPs. There is no coordination between various fault conditions that could impact loss measurement. This is also true for conditions where MEPs are placed in shutdown state as a result of linkage to a redundancy scheme like MC-LAG. Loss measurement is based on the ETH-SL and not coordinated across different functional aspects on the network element. ETH-SL is supported on service based MEPs.

It is possible that two MEPs may be configured with the same MAC on different remote nodes. This causes various issues in the FDB for multipoint services and is considered a misconfiguration for most services. It is possible to have a valid configuration where multiple MEPs on the same remote node have the same MAC. In fact, this is likely to happen. In this release, only the first responder is used to measure packet loss. The second responder is dropped. Since the same MAC for multiple MEPs is only truly valid on the same remote node this should is an acceptable approach.

There is no way for the responding node to understand when a test is completed. For this reason a configurable “inactivity-timer” determines the length of time a test is valid. The timer will maintain an active test as long as it is receiving packets for that specific test, defined by the test-id, remote MEP Id and source MAC. When there is a gap between the packets that exceeds the inactivity-timer the responding node responds with a sequence number of one regardless of what the sequence number was the instantiating node sent. This means the remote MEP accepts that the previous test has expired and these probes are part of a new test. The default for the inactivity timer is 100 second and has a range of 10 to 100 seconds.

The responding node is limited to a fixed number of SLM tests per platform. Any test that attempts to involve a node that is already actively processing more than the system limit of the SLM tests shows up as “out loss” or “unacknowledged” packets on the node that instantiated the test because the packets are silently discarded at the responder. It is important for the operator to understand this is silent and no log entries or alarms is raised. It is also important to keep in mind that these packets are ETH-CFM based and the different platforms stated receive rate for ETH-CFM must not be exceeded. ETH-SL provides a mechanism for operators to pro-actively trend packet loss for service based MEPs.

3.3.6.1. Configuration example

The following figure shows the configuration required for proactive SLM test using SAA.

Figure 24:  SLM example 

The output from the MIB is shown as follows as an example of an on-demand test. Node1 is tested for this example. The SAA configuration does not include the accounting policy required to collect the statistics before they are overwritten. NODE2 does not have an SAA configuration. NODE2 includes the configuration to build the MEP in the VPLS service context.

config>eth-cfm# info

----------------------------------------------

     domain 3 format none level 3

          association 1 format icc-based name "03-0000000100"

               bridge-identifier 100

               exit

               ccm-interval 1

               remote-mepid 101

          exit

     exit

----------------------------------------------

*A:7210SAS>config>service>vpls# info

----------------------------------------------

stp

shutdown

exit

sap 1/1/3:100.100 create

exit

sap lag-1:100.100 create

eth-cfm

mep 100 domain 3 association 1 direction down

ccm-enable

mac-address d0:0d:1e:00:01:00

no shutdown

exit

exit

exit

no shutdown

----------------------------------------------

*A:7210SAS>config>service>vpls

 

*A:7210SAS>config>saa# info detail

----------------------------------------------

        test "SLM" owner "TiMOS CLI"

            no description

            type

                eth-cfm-two-way-

slm 00:01:22:22:33:34 mep 1 domain 1 association 1 size 0 fc "nc" count 100 timeout 

1 interval 1

            exit

            trap-gen

                no probe-fail-enable

                probe-fail-threshold 1

                no test-completion-enable

                no test-fail-enable

                test-fail-threshold 1

exit

continuous

no shutdown

exit

----------------------------------------------

*A:7210SAS>config>saa#

 

*A:7210SAS# show saa SLM42

 

===============================================================================

SAA Test Information

===============================================================================

Test name                    : SLM42

Owner name                   : TiMOS CLI

Description                  : N/A

Accounting policy            : None

Continuous                   : Yes

Administrative status        : Enabled

Test type                    : eth-cfm-two-way-slm 00:25:ba:02:a6:50 mep 4

                               domain 1 association 1 fc "h1" count 100

                               timeout 1 interval 1

Trap generation              : None

Test runs since last clear   : 117

Number of failed test runs   : 1

Last test result             : Success

-------------------------------------------------------------------------------

Threshold

Type        Direction Threshold  Value      Last Event          Run #

-------------------------------------------------------------------------------

Jitter-in   Rising    None       None       Never               None     

            Falling   None       None       Never               None     

Jitter-out  Rising    None       None       Never               None     

            Falling   None       None       Never               None     

Jitter-rt   Rising    None       None       Never               None     

            Falling   None       None       Never               None     

Latency-in  Rising    None       None       Never               None     

            Falling   None       None       Never               None     

Latency-out Rising    None       None       Never               None     

            Falling   None       None       Never               None     

Latency-rt  Rising    None       None       Never               None     

            Falling   None       None       Never               None     

Loss-in     Rising    None       None       Never               None     

            Falling   None       None       Never               None     

Loss-out    Rising    None       None       Never               None     

            Falling   None       None       Never               None     

Loss-rt     Rising    None       None       Never               None     

            Falling   None       None       Never               None     

 

===============================================================================

Test Run: 116

Total number of attempts: 100

Number of requests that failed to be sent out: 0

Number of responses that were received: 100

Number of requests that did not receive any response: 0

Total number of failures: 0, Percentage: 0

 (in ms)            Min          Max      Average       Jitter

Outbound  :         8.07         8.18         8.10        0.014

Inbound   :        -7.84        -5.46        -7.77        0.016

Roundtrip :        0.245         2.65        0.334        0.025

Per test packet: 

  Sequence     Outbound      Inbound    RoundTrip Result

         1         8.12        -7.82        0.306 Response Received

         2         8.09        -7.81        0.272 Response Received

         3         8.08        -7.81        0.266 Response Received

         4         8.09        -7.82        0.270 Response Received

         5         8.10        -7.82        0.286 Response Received

         6         8.09        -7.81        0.275 Response Received

         7         8.09        -7.81        0.271 Response Received

         8         8.09        -7.82        0.277 Response Received

         9         8.11        -7.81        0.293 Response Received

        10         8.10        -7.82        0.280 Response Received

        11         8.11        -7.82        0.293 Response Received

        12         8.10        -7.82        0.287 Response Received

        13         8.10        -7.82        0.286 Response Received

        14         8.09        -7.82        0.276 Response Received

        15         8.10        -7.82        0.284 Response Received

        16         8.09        -7.82        0.271 Response Received

        17         8.11        -7.81        0.292 Response Received

===============================================================================

#oam eth-cfm two-way-slm-test 00:25:ba:04:39:0c mep 4 domain 1 association 1 send-

count

10 interval 1 timeout 1

Sending 10 packets to 00:25:ba:04:39:0c from MEP 4/1/1 (Test-id: 143

Sent 10 packets, 10 packets received from MEP ID 3, (Test-id: 143)

(0 out-loss, 0 in-loss, 0 unacknowledged)

 

*A:7210SAS>show# eth-cfm mep 4 domain 1 association 1 two-way-slm-test

 

===============================================================================

Eth CFM Two-way SLM Test Result Table (Test-id: 143)

===============================================================================

Peer Mac Addr      Remote MEP       Count     In Loss    Out Loss         Unack

-------------------------------------------------------------------------------

00:25:ba:04:39:0c           3          10           0           0            0

===============================================================================

*A:7210SAS>show#

 

 

3.3.7. ETH-CFM QoS considerations

UP MEPs and DOWN MEPs have been aligned as of this release to better emulate service data. When an UP MEP or DOWN MEP is the source of the ETH-CFM PDU the priority value configured, as part of the configuration of the MEP or specific test, will be treated as the Forwarding Class (FC) by the egress QoS policy. If there is no egress QoS policy the priority value will be mapped to the CoS values in the frame. However, egress QoS Policy may overwrite this original value. The Service Assurance Agent (SAA) uses fc fc-name to accomplish similar functionality.

UP MEPs and DOWN MEPs terminating an ETH-CFM PDU will use the received FC as the return priority for the appropriate response, again feeding into the egress QoS policy as the FC.

ETH-CFM PDUs received on the MPLS-SDP bindings will now correctly pass the EXP bit values to the ETH-CFM application to be used in the response.

These are default behavioral changes without CLI options.

3.3.8. ETH-CFM configuration guidelines

The following lists ETH-CFM configuration guidelines:

3.4.1. CFM connectivity fault conditions

CFM MEP declares a connectivity fault when its defect flag is equal to or higher than its configured lowest defect priority. The defect can be any of the following depending on configuration:

The following additional fault condition applies to Y.1731 MEPs:

Setting the lowest defect priority to allDef may cause problems when fault propagation is enabled in the MEP. In this scenario, when MEP A sends CCM to MEP B with interface status down, MEP B will respond with a CCM with RDI set. If MEP A is configured to accept RDI as a fault, then it gets into a dead lock state, where both MEPs will declare fault and never be able to recover.

The default lowest defect priority is DefMACstatus, which will not be a problem when interface status TLV is used. It is also very important that different Ethernet OAM strategies should not overlap the span of each other. In some cases, independent functions attempting to perform their normal fault handling can negatively impact the other. This interaction can lead to fault propagation in the direction toward the original fault, a false positive, or worse, a deadlock condition that may require the operator to modify the configuration to escape the condition. For example, overlapping Link Loss Forwarding (LLF) and ETH-CFM fault propagation could cause these issues.

For the DefRemoteCCM fault, it is raised when any remote MEP is down. So whenever a remote MEP fails and fault propagation is enabled, a fault is propagated to SMGR.

3.4.2. CFM fault propagation methods

When CFM is the OAM module at the other end, it is required to use any of the following methods (depending on local configuration) to notify the remote peer:

Note: 7210 platforms expect that the fault notified using interface status TLV, is cleared explicitly by the remote MEP when the fault is no longer present on the remote node. On 7210 SAS, use of CCM with interface status TLV Down is not recommended to be configured with a Down MEP, unless it is known that the remote MEP clears the fault explicitly.

User can configure UP MEPs to use Interface Status TLV with fault propagation. Special considerations apply only to Down MEPs.

When a fault is propagated by the service manager, if AIS is enabled on the SAP/SDP-binding, then AIS messages are generated for all the MEPs configured on the SAP/SDP-binding using the configured levels.

Note that the existing AIS procedure still applies even when fault propagation is disabled for the service or the MEP. For example, when a MEP loses connectivity to a configured remote MEP, it generates AIS if it is enabled. The new procedure that is defined in this document introduces a new fault condition for AIS generation, fault propagated from SMGR, that is used when fault propagation is enabled for the service and the MEP.

The transmission of CCM with interface status TLV must be done instantly without waiting for the next CCM transmit interval. This rule applies to CFM fault notification for all services.

Notifications from SMGR to the CFM MEPs for fault propagation should include a direction for the propagation (up or down: up means in the direction of coming into the SAP/SDP-binding; down means in the direction of going out of the SAP/SDP-binding), so that the MEP knows what method to use. For instance, an up fault propagation notification to a down MEP will trigger an AIS, while a down fault propagation to the same MEP can trigger a CCM with interface TLV with status down.

For a specific SAP/SDP-binding, CFM and SMGR can only propagate one single fault to each other for each direction (up or down).

When there are multiple MEPs (at different levels) on a single SAP/SDP-binding, the fault reported from CFM to SMGR will be the logical OR of results from all MEPs. Basically, the first fault from any MEP will be reported, and the fault will not be cleared as long as there is a fault in any local MEP on the SAP/SDP-binding.

3.4.3. Epipe services

Down and up MEPs are supported for Epipe services as well as fault propagation. When there are both up and down MEPs configured in the same SAP/SDP-binding and both MEPs have fault propagation enabled, a fault detected by one of them will be propagated to the other, which in turn will propagate fault in its own direction.

3.4.4. Fault propagation to access dot1q/QinQ ports on the 7210 SAS-T in access-uplink mode

A fault on the access-uplink port brings down all access ports with services independent of the encapsulation type of the access port (null, dot1q, or QinQ), that is, support Link Loss Forwarding (LLF). A fault propagated from the access-uplink port to access ports is based on configuration. A fault is propagated only in a single direction from the access-uplink port to access port.

A fault on the access-uplink port is detected using Loss of Signal (LoS) and EFM-OAM.

The following figure shows local fault propagation.

Figure 25:  Local fault propagation  

3.4.4.1. Configuring fault propagation

The operational group functionality, also referred to as oper-group, is used to detect faults on access-uplink ports and propagate them to all interested access ports regardless of their encapsulation. On the 7210 SAS operating in access-uplink mode, ports can be associated with oper-groups. Perform the following procedure to configure the use of the oper-group functionality for fault detection on a port and monitor-oper-group to track the oper-group status and propagate the fault based on the operational state of the oper-group.

1. Create an oper-group (for example, “uplink-to-7210”).
2. Configure an access-uplink port to track its operational state (for example, 1/1/20) and associate it with the oper-group created in 1 (that is, uplink-to-7210).
3. Configure dot1q access ports for which the operational state must be driven by the operational state of the access-uplink port (for example, 1/1/1 and 1/1/5) as the monitor-oper-group.
4. To detect a fault on the access-uplink port and change the operational state, use either the LoS or EFM OAM feature.
5. When the operational state of the access-uplink port changes from up to down, the state of all access ports configured to monitor the group changes to down. Similarly, a change in state from down to up changes the operational state of the access port to up. When the operational state of the access port is brought down, the laser of the port is also shut down. The hold-timers command is supported to avoid the flapping of links.

3.4.4.1.1. Configuration example for fault propagation using oper-group

The following is a sample oper-group system configuration output.

Note: Refer to the 7210 SAS-Mxp, R6, R12, S, Sx, T Basic System Configuration Guide for more information about this CLI.

*A:7210SAS>config>system>oper-group# info detail

----------------------------------------------

            hold-time

                group-down 0

                group-up 4

            exit

----------------------------------------------

*A:7210SAS>config>system>oper-group#

3.4.5. Fault propagation to access dot1q/QinQ ports on the 7210 SAS-Sx/S 1/10GE and 7210 SAS-Sx 10/100GE in standalone mode

Note: An uplink port refers to an access port or LAG or hybrid port or LAG that is facing the network core.

A fault on the uplink port or LAG brings down all access ports with services independent of the encapsulation type of the access port (null, dot1q, or QinQ), that is, support Link Loss Forwarding (LLF). A fault propagated from the uplink port or LAG to access ports is based on configuration. A fault is propagated only in a single direction from the uplink port or LAG to access port.

A fault on the uplink port or LAG is detected using Loss of Signal (LoS) and EFM-OAM.

The following figure show local fault propagation.

Figure 26:  Local fault propagation  

3.4.5.1. Configuring fault propagation

The oper-group functionality is used to detect faults on uplink ports or LAGs and propagate them to all interested access ports regardless of their encapsulation. On the 7210 SAS, ports or LAGs can be associated with oper-groups. Perform the following procedure to configure the use of the oper-group functionality for fault detection on a port or LAG and monitor-oper-group to track the oper-group status and propagate the fault based on the operational state of the oper-group:

1. Create an oper-group (for example, “uplink-to-7210”).
2. Configure an uplink port or LAG to track its operational state (for example, 1/1/20) and associate it with the oper-group created in 1 (that is, uplink-to-7210).
3. Configure dot1q access ports for which the operational state must be driven by the operational state of the uplink port or LAG (for example, 1/1/1 and 1/1/5) as the monitor-oper-group.
4. To detect a fault on the uplink port or LAG and change the operational state, use either the LoS or EFM OAM feature.
5. When the operational state of the uplink port or LAG changes from up to down, the state of all access ports configured to monitor the group changes to down. Similarly, a change in state from down to up changes the operational state of the access port to up. When the operational state of the access port is brought down, the laser of the port is also shut down. The hold-timers command is supported to avoid the flapping of links.

3.4.5.1.1. Configuration example for fault propagation using oper-group

The following is a sample oper-group system configuration output.

Note: Refer to the 7210 SAS-Mxp, R6, R12, S, Sx, T Basic System Configuration Guide for more information about this CLI.

*A:7210SAS>config>system>oper-group# info detail

----------------------------------------------

            hold-time

                group-down 0

                group-up 4

            exit

----------------------------------------------

*A:7210SAS>config>system>oper-group#

3.5.1. SAA two-way timing

SAA allows two-way timing for several applications. This provides the carrier and their customers with data to verify that the SLA agreements are being correctly enforced.

3.5.2. Configuring SAA test parameters

The following is a sample SAA configuration output.

3.6.1. Prerequisites for using the testhead tool

This section describes the prerequisites for using the Testhead tool.

3.6.2. Configuration guidelines

This section provide the configuration guidelines for this feature (that is, testhead OAM tool). It is applicable to all the platforms described in this guide unless a specific platform is called out explicitly:

3.6.3. Configuring testhead tool parameters

The following is a sample port loopback MAC swap configuration output using the service and SAP.

The following is a sample port loopback with MAC swap configuration output on the remote end.

The following is a sample testhead profile configuration output.

The following command is used to execute the testhead profile.

3.7.1. Session

This is the overall collection of different tests, the test parameters, measurement intervals, and mapping to configured storage models. It is the overall container that defines the attributes of the session:

The session can be viewed as the single container that brings all aspects of individual tests and the various OAM-PM components under a single umbrella. If any aspects of the session are incomplete, the individual test cannot be activated with a no shutdown command, and an "Invalid ethernet session parameters" error will occur.

3.7.2. Standard PM packets

A number of standards bodies define performance monitoring packets that can be sent from a source, processed, and responded to by a reflector. The protocols available to carry out the measurements are based on the test family type configured for the session.

Ethernet PM delay measurements are carried out using the Two Way Delay Measurement Protocol version 1 (DMMv1) defined in Y.1731 by the ITU-T. This allows for the collection of Frame Delay (FD), InterFrame Delay Variation (IFDV), Frame Delay Range (FDR), and Mean Frame Delay (MFD) measurements for round trip, forward, and backward directions.

DMMv1 adds the following to the original DMM definition:

DMMv1 and DMM are backwards compatible and the interaction is defined in Y.1731 ITU-T-2011 Section 11 "OAM PDU validation and versioning".

Ethernet PM loss measurements are carried out using Synthetic Loss Measurement (SLM), which is defined in Y.1731 by the ITU-T. This allows for the calculation of Frame Loss Ratio (FLR) and availability.

A session can be configured with one or more tests. Depending on the session test type family, one or more test configurations may need to be included in the session to gather both delay and loss performance information. Each test that is configured shares the common session parameters and the common measurement intervals. However, each test can be configured with unique per-test parameters. Using Ethernet as an example, both DMM and SLM would be required to capture both delay and loss performance data.

Each test must be configured with a TestID as part of the test parameters, which uniquely identifies the test within the specific protocol. A TestID must be unique within the same test protocol. Again using Ethernet as an example, DMM and SLM tests within the same session can use the same TestID because they are different protocols. However, if a TestID is applied to a test protocol (like DMM or SLM) in any session, it cannot be used for the same protocol in any other session. When a TestID is carried in the protocol, as it is with DMM and SLM, this value does not have global significance. When a responding entity must index for the purpose of maintaining sequence numbers, as in the case of SLM, the TestID, Source MAC, and Destination MAC are used to maintain the uniqueness of the responder. This means that the TestID has only local, and not global, significance.

3.7.3. Measurement intervals

A measurement interval is a window of time that compartmentalizes the gathered measurements for an individual test that have occurred during that time. Allocation of measurement intervals, which equates to system memory, is based on the metrics being collected. This means that when both delay and loss metrics are being collected, they allocate their own set of measurement intervals. If the operator is executing multiple delay and loss tests under a single session, then multiple measurement intervals will be allocated, with one interval allocated per criteria per test.

Measurement intervals can be 15 minutes (15-min), one hour (1-hour) and 1 day (1-day) in duration. The boundary-type defines the start of the measurement interval and can be aligned to the local time of day clock, with or without an optional offset. The boundary-type can be aligned using the test-aligned option, which means that the start of the measurement interval coincides with the activation of the test. By default the start boundary is clock-aligned without an offset. When this configuration is deployed, the measurement interval will start at zero, in relation to the length. When a boundary is clock-aligned and an offset is configured, the specified amount of time will be applied to the measurement interval. Offsets are configured on a per-measurement interval basis and only applicable to clock-aligned measurement intervals. Only offsets less than the measurement interval duration are allowed. The following table describes some examples of the start times of each measurement interval.

Although test-aligned approaches may seem beneficial for simplicity, there are some drawbacks that need to be considered. The goal of the time-based and well defined collection windows allows for the comparison of measurements across common windows of time throughout the network and for relating different tests or sessions. It is suggested that proactive sessions use the default clock-aligned boundary type. On-demand sessions may make use of test-aligned boundaries. On-demand tests are typically used for troubleshooting or short term monitoring that does not require alignment or comparison to other PM data.

The statistical data collected and the computed results from each measurement interval are maintained in volatile system memory by default. The number of intervals stored is configurable per measurement interval. Different measurement intervals will have different defaults and ranges. The interval-stored parameter defines the number of completed individual test runs to store in volatile memory. There is an additional allocation to account for the active measurement interval. To look at the statistical information for the individual tests and a specific measurement interval stored in volatile memory, the show oam-pm statistics … interval-number command can be used. If there is an active test, it can be viewed by using the interval number 1. In this case, the first completed record would be interval number 2, and previously completed records would increment up to the maximum intervals stored value plus one.

As new tests for the measurement interval are completed, the older entries are renumbered to maintain their relative position to the current test. If the retained test data for a measurement interval consumes the final entry, any subsequent entries cause the removal of the oldest data.

There are drawbacks to this storage model. Any high availability function that causes an active CPM switch will flush the results that are in volatile memory. Another consideration is the large amount of system memory consumed using this type of model. With the risks and resource consumption this model incurs, an alternate method of storage is supported.

An accounting policy can be applied to each measurement interval to write the completed data in system memory to non-volatile flash memory in an XML format. The amount of system memory consumed by historically completed test data must be balanced with an appropriate accounting policy. Nokia recommends that only necessary data be stored in non-volatile memory to avoid unacceptable risk and unnecessary resource consumption. It is further suggested that a large overlap between the data written to flash memory and stored in volatile memory is unnecessary.

The statistical information in system memory is also available through SNMP. If this method is chosen, a balance must be struck between the intervals retained and the times at which the SNMP queries collect the data. Determining the collection times through SNMP must be done with caution. If a file is completed while another file is being retrieved through SNMP, then the indexing will change to maintain the relative position to the current run. Correct spacing of the collection is key to ensuring data integrity.

The OAM-PM XML file contains the keywords and MIB references described in the following table.

By default, the 15-min measurement interval stores 33 test runs (32+1) with a configurable range of 1 to 96, and the 1-hour measurement interval stores 9 test runs (8+1) with a configurable range of 1 to 24. The only storage for the 1-day measurement interval is 2 (1+1). This value for the 1-day measurement interval cannot be changed.

All three measurement intervals may be added to a single session if required. Each measurement interval that is included in a session is updated simultaneously for each test that is executing. If a measurement interval length is not required, it should not be configured. In addition to the three predetermined length measurement intervals, a fourth “always on” raw measurement interval is allocated at test creation. Data collection for the raw measurement interval commences immediately following the execution of a no shutdown command. It is a valuable tool for assisting in real-time troubleshooting as it maintains the same performance information and relates to the same bins as the fixed length collection windows. The operator may clear the contents of the raw measurement interval and flush stale statistical data to look at current conditions. This measurement interval has no configuration options, cannot be written to flash memory, and cannot be disabled; It is a single never-ending window.

Memory allocation for the measurement intervals is performed when the test is configured. Volatile memory is not flushed until the test is deleted from the configuration, a high availability event causes the backup CPM to become the newly active CPM, or some other event clears the active CPM system memory. Shutting down a test does not release the allocated memory for the test.

Measurement intervals also include a suspect flag. The suspect flag is used to indicate that data collected in the measurement interval may not be representative. The flag will be set to true only under the following conditions:

The suspect flag is not set when there are times of service disruption, maintenance windows, discontinuity, low packet counts, or other such events. Higher level systems would be required to interpret and correlate those types of event for measurement intervals which executed during the time that relate to the specific interruption or condition. Since each measurement interval contains a start and stop time, the information is readily available for higher level systems to discount the specific windows of time.

3.7.4. Data structures and storage

There are two main metrics that are the focus of OAM-PM: delay and loss. The different metrics have two unique storage structures and will allocate their own measurement intervals for these structures. This occurs regardless of whether the performance data is gathered with a single packet or multiple packet types.

Delay metrics include Frame Delay (FD), InterFrame Delay Variation (IFDV), Frame Delay Range (FDR) and Mean Frame Delay (MFD). Unidirectional and round trip results are stored for each metric:

FD, IFDV and FDR statistics are binnable results. FD, IFDV, FDR and MFD all include minimum, maximum, and average values. Unidirectional and round trip results are stored for each metric.

Unidirectional frame delay and frame delay range measurements require exceptional time of day clock synchronization. If the time of day clock does not exhibit extremely tight synchronization, unidirectional measurements will not be representative. In one direction, the measurement will be artificially increased by the difference in the clocks. In the other direction, the measurement will be artificially decreased by the difference in the clocks. This level of clocking accuracy is not available with NTP. To achieve this level of time of day clock synchronization, Precision Time Protocol (PTP) 1588v2 should be considered.

Round trip metrics do not require clock synchronization between peers, since the four timestamps allow for accurate representation of the round trip delay. The mathematical computation removes remote processing and any difference in time of day clocking. Round trip measurements do require stable local time of day clocks.

Any delay metric that is negative will be treated as zero and placed in bin 0, the lowest bin which has a lower boundary of 0 microseconds.

Delay results are mapped to the measurement interval that is active when the result arrives back at the source.

There are no supported log events based on delay metrics.

Loss metrics are only unidirectional and will report frame loss ratio (FLR) and availability information. Frame loss ratio is the computation of loss (lost/sent) over time. Loss measurements during periods of unavailability are not included in the FLR calculation as they are counted against the unavailability metric.

Availability requires relating three different functions. First, the individual probes are marked as available or unavailable based on sequence numbers in the protocol. A number of probes are rolled up into a small measurement window, typically 1 s. Frame loss ratio is computed over all the probes in a small window. If the resulting percentage is higher than the configured threshold, the small window is marked as unavailable. If the resulting percentage is lower than the threshold, the small window is marked as available. A sliding window is defined as some number of small windows, typically 10. The sliding window is used to determine availability and unavailability events. Switching from one state to the other requires every small window in the sliding window to be the same state and different from the current state.

Availability and unavailability counters are incremented based on the number of small windows that have occurred in all available and unavailable windows.

Availability and unavailability using synthetic loss measurements is meant to capture the loss behavior for the service. It is not meant to capture and report on service outages or communication failures. Communication failures of a bidirectional or unidirectional nature must be captured using some other means of connectivity verification, alarming, or continuity checking. During times of complete or extended failure periods it becomes necessary to timeout individual test probes. It is not possible to determine the direction of the loss because no response packets are being received back on the source. In this case, the statistics calculation engine maintains the previous state, updating the appropriate directional availability or unavailability counter. At the same time, an additional per-direction undetermined counter is updated. This undetermined counter is used to indicate that the availability or unavailability statistics could not be determined for a number of small windows.

During connectivity outages, the higher level systems can be used to discount the loss measurement interval, which covers the same span as the outage.

Availability and unavailability computations may delay the completion of a measurement interval. The declaration of a state change or the delay to a closing a measurement interval could be equal to the length of the sliding window and the timeout of the last packet. Closing of a measurement interval cannot occur until the sliding window has determined availability or unavailability. If the availability state is changing and the determination is crossing two measurement intervals, the measurement interval will not complete until the declaration has occurred. Typically, standard bodies indicate the timeout per packet. In the case of Ethernet, DMMv1, and SLM, timeout values are set at 5 s and cannot be configured.

There are no log events based on availability or unavailability state changes.

During times of availability, there can be times of high loss intervals (HLI) or consecutive high loss intervals (CHLI). These are indicators that the service was available but individual small windows or consecutive small windows experienced frame loss ratios exceeding the configured acceptable limit. A HLI is any single small window that exceeds the configured frame loss ratio. This could equate to a severely errored second, assuming the small window is one second. A CHIL is a consecutive high loss interval that exceeds a consecutive threshold within the sliding window. Only one HLI will be counted for a window.

Availability can only be reasonably determined with synthetic packets. This is because the synthetic packet is the packet being counted and provides a uniform packet flow that can be used for the computation. Transmit and receive counter-based approaches cannot reliably be used to determine availability because there is no guarantee that service data is on the wire, or the service data on the wire uniformity could make it difficult to make a declaration valid.

The following figure shows loss in a single direction using synthetic packets, and demonstrates what happens when a possible unavailability event crosses a measurement interval boundary. In the diagram, the first 13 small windows are all marked available (1), which means that the loss probes that fit into each of those small windows did not equal or exceed a frame loss ratio of 50%. The next 11 small windows are marked as unavailable, which means that the loss probes that fit into each of those small windows were equal to or above a frame loss ratio of 50%. After the 10th consecutive small window of unavailability, the state transitions from available to unavailable. The 25th small window is the start of the new available state which is declared following the 10th consecutive available small window. Notice that the frame loss ratio is 00.00%; this is because all the small windows that are marked as unavailable are counted toward unavailability, and as such are excluded from impacting the FLR. If there were any small windows of unavailability that were outside of an unavailability event, they would be marked as HLI or CHLI and be counted as part of the frame loss ratio.

Figure 29:  Evaluating and computing loss and availability 

3.7.5. Bin groups

Bin groups are templates that are referenced by the session. Three types of binnable statistics are available: FD, IFDV, and FDR, all of which are available in forward, backward, and round trip directions. Each of these metrics can have up to ten bin groups configured to group the results. Bin groups are configured by indicating a lower boundary. Bin 0 has a lower boundary that is always zero and is not configurable. The microsecond range of the bins is the difference between the adjacent lower boundaries. For example, bin-type fd bin 1 configured with lower-bound 1000 means that bin 0 will capture all frame delay statistics results between 0 and 1 ms. Bin 1 will capture all results above 1 ms and below the bin 2 lower boundary. The last bin to be configured would represent the bin that collects all the results at and above that value. Not all ten bins must be configured.

Each binnable delay metric type requires their own values for the bin groups. Each bin in a type is configurable for one value. It is not possible to configure a bin with different values for round trip, forward, and backward. Consideration must be given to the configuration of the boundaries that represent the important statistics for that specific service.

As stated earlier in this section, this is not a dynamic environment. If a bin group is being referenced by any active test the bin group cannot shutdown. To modify the bin group it must be shut down. If the configuration of a bin group must be changed, and a large number of sessions are referencing the bin group, migrating existing sessions to a new bin group with the new parameters can be considered to reduce the maintenance window. To modify any session parameter, every test in the session must be shut down.

Bin group 1 is the default bin group. Every session requires a bin group to be assigned. By default, bin group 1 is assigned to every OAM-PM session that does not have a bin group explicitly configured. Bin group 1 cannot be modified. The bin group 1 configuration parameters are as follows:

3.7.6. Relating the components

The following figure shows the architecture of all of the OAM-PM concepts previously described. It shows a more detailed hierarchy than previously shown in the introduction. This shows the relationship between the tests, the measurement intervals, and the storage of the results.

Figure 30:  Relating OAM-PM components 

3.7.7. Monitoring

The following configuration examples are used to demonstrate the different show and monitoring commands available to check OAM-PM.