OAM and SAA

The following guidelines and restrictions apply:

• LDP LER ECMP is not supported. The following description on LDP ECMP as an LER node does not apply to 7210 SAS nodes.

• The 7210 SAS supports LDP and BGP 3107 labeled routes. The 7210 SAS does not support LDP FEC stitching to BGP 3107 labeled route to LDP FEC stitching and vice-versa. The following description about stitching of BGP 3107 labeled routes to LDP FEC is provided to describe the behavior in an end-to-end network solution deployed using 7210 SAS and 7750 SR nodes, with 7210 SAS nodes acting as the LER node.

• The 7210 SAS does not support ECMP for BGP 3107 labeled routes. The description on use of ECMP routes for BGP 3107 labeled routes does not apply to the 7210 SAS. It is provided as follows for completeness and better understanding of the behavior in end-to-end network solution deployed using 7210 SAS and 7750 SR 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.

MPLS OAM supports segment routing extensions to lsp-ping and lsp-trace as specified 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.

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

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:

• tunnel connectivity

• VC label mapping verification

• service existence

• service provisioned parameter verification

• round trip path verification

• service dynamic configuration verification

The Epipe diagnostic tool is described in the CPE ping for Epipe section. CPE ping for Epipe provides the ability to check network connectivity to the specified client device within the Epipe.

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:

• MAC ping

  Provides an end-to-end test to identify the egress customer-facing port where a customer MAC was learned. MAC ping can also be used with a broadcast MAC address to identify all egress points of a service for the specified broadcast MAC.

• MAC trace

  Provides the ability to trace a specified MAC address hop-by-hop until the last node in the service domain. An SAA test with MAC trace is considered successful when there is a reply from a far-end node indicating that they have the destination MAC address on an egress SAP or the CPM.

• CPE ping

  Provides the ability to check network connectivity to the specified client device within the VPLS. CPE ping will return the MAC address of the client, as well as the SAP and PE at which it was learned.

• MAC populate

  Allows specified MAC addresses to be injected in the VPLS service domain. This triggers learning of the injected MAC address by all participating nodes in the service. This tool is generally followed by MAC ping or MAC trace to verify if correct learning occurred.

• MAC purge

  Allows MAC addresses to be flushed from all nodes in a service domain.

This section describes VLL diagnostics.

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

• the session-sender

• the server

• the session-reflector

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.

TWAMP Light is an optional model included in the TWAMP standard RFC 5357 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 (A Two-Way Active 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, 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 a 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 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. If the source IP address in the TWAMP Light packet arriving on the responder does not match a configured IP address prefix, the packet is dropped. Multiple prefix entries may be configured per context on the responder. An inactivity timeout under the config>test-oam>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-PM section of this guide provides more information describing the integration of TWAMP Light and the OAM-PM architecture, including hardware dependencies.

The following TWAMP Light functions are supported on the 7210 SAS-K 2F1C2T:

• base router instance for IES services

• IPv4 (must be unicast)

• reflector prefix definition for acceptable TWAMP Light sources:

  • A prefix list may be added and removed without shutting down the reflector function.

  • If no prefixes are defined, the reflector will drop all TWAMP Light packets.

• integration with OAM-PM architecture capturing delay and loss measurement statistics:

  • Not available from interactive CLI.

  • Multiple test sessions can be configured between the same source and destination IP endpoints. The tuple of Source IP, Destination IP, Source UDP, and Destination UDP provide a unique index for each test.

The following TWAMP Light functions are supported on the 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C:

• base router instances for network interfaces and IES services

• per-VPRN service context

• IPv4 and IPv6 (must be unicast):

• reflector prefix definition for acceptable TWAMP Light sources:

  • A prefix list may be added and removed without shutting down the reflector function.

  • If no prefixes are defined, the reflector will drop all TWAMP Light packets.

• integration with OAM-PM architecture capturing delay and loss measurement statistics:

  • Not available from interactive CLI.

  • Multiple test sessions can be configured between the same source and destination IP endpoints. The tuple of Source IP, Destination IP, Source UDP, and Destination UDP provide a unique index for each test.

config>test-oam>twamp>twamp-light# info detail
--------------------------------------------------------------------------
(default)      inactivity-timeout 100 
-------------------------------------------------------------------------- 

config>service>vprn# info
--------------------------------------------------------------------------- 
            route-distinguisher 65535:500
            auto-bind ldp
            vrf-target target:65535:500
            interface "to-cpe31" create
                address 10.1.1.1/30
                sap 1/1/2:500 create
                exit
            exit
            static-route 192.168.1.0/24 next-hop 10.1.1.2
            bgp
                no shutdown
            exit
            twamp-light
                reflector udp-port 15000 create
                    description "TWAMP Light reflector VPRN 500"
                    prefix 10.2.1.1/32 create
                        description "Process only 10.2.1.1 TWAMP Light Packets"
                    exit
                    prefix 172.16.1.0/24 create
                        description "Process all 172.16.1.0 TWAMP Light packets"
                    exit
                    no shutdown
                exit
            exit
            no shutdown
------------------------------------------------------------------------------

config>service>vprn# info
-------------------------------------------------------------------------
            route-distinguisher 65535:500
            auto-bind ldp
            vrf-target target:65535:500
            interface "to-cpe28" create
                address 10.2.1.1/30
                sap 1/1/4:500 create
                exit
            exit
            static-route 192.168.2.0/24 next-hop 10.2.1.2
            no shutdown
------------------------------------------------------------------------- 

config>oam-pm>session# info detail
-------------------------------------------------------------------------
            bin-group 2
            meas-interval 15-mins create
                intervals-stored 8
            exit
            ip
                dest-udp-port 15000
                destination 10.1.1.1
                fc "l2"
(default)           no forwarding 
                profile in
                router 500
                source 10.2.1.1
(default)          ttl 255  
                twamp-light test-id 500 create
(default)              interval 100
(default)              pad-size 0
(default)              no test-duration
                   no shutdown
                exit
            exit
------------------------------------------------------------------------- 

The IEEE and the ITU-T use their own nomenclature when describing administrative contexts and functions. This introduces a level of complexity to configuration, discussion 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, as follows:

• 0

  Undefined and reserved by the IEEE.

• 1

  No domain name. It is the only format supported by Y.1731 as the ITU-T specification does not use the domain name. This is supported in the IEEE 802.1ag standard but not in currently implemented for 802.1ag defined contexts.

• 2,3,4

  Provides the ability to input various different textual formats, up to 45 characters. The string format (2) is the default and therefore the keyword is not shown when looking at the configuration.

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 IEEE format options, as follows:

• 1 (Primary VID) - Values 0 — 4094

• 2 (String) - raw ASCII, excluding 0-31 decimal/0-1F hex (which are control characters) form the ASCII table

• 3 (2-octet integer) - 0 — 65535

• 4 (VPN ID) - hex value as described in RFC 2685, Virtual Private Networks Identifier

• 32 (icc-format) — exactly 13 characters from the ITU-T recommendation T.50

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.

ETH-CFM support matrix for 7210 SAS-D, ETH-CFM support matrix for 7210 SAS-Dxp, ETH-CFM support matrix for 7210 SAS-K 2F1C2T, ETH-CFM support matrix for 7210 SAS-K 2F6C4T, and ETH-CFM support matrix for 7210 SAS-K 3SFP+ 8C are general tables that indicates the ETH-CFM support for the different services and endpoints. They are 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.

Timestamps for different Y.1731 messages are obtained as follows:

• The 7210 SAS-D support is as follows:

  • Y.1731 2-DM messages for Down MEPs uses hardware timestamps for both Rx (packets received by the node) and Tx (packets sent out of the node). The timestamps is obtained from a free-running hardware clock. It provides accurate 2-way delay measurements and it is not recommended to use for computing 1-way delay.

  • Y.1731 2-DM messages for Up MEPs, 1-DM for both Down MEPs and UP MEPs, and 2-SLM for both Down MEPs and Up MEPs use software based timestamps on Tx and hardware based timestamp on Rx. It uses the system clock (free-running or synchronized to NTP) to obtain the timestamps.

• For the 7210 SAS-Dxp, Y.1731 2-DM and 1-DM messages for both Down MEPs and Up MEPs use software-based timestamps on Tx and hardware-based timestamps on Rx. Timestamps are obtained from the system clock, which is free-running or synchronized to NTP.

• The 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, and 7210 SAS-K 3SFP+ 8C support hardware time-stamping for Y.1731 1-DM, 2-DM and SLM. The timestamp values are obtained using a synchronized clock. The synchronized clock provides timestamp values as follows:

  • When neither PTP nor NTP is enabled in the system, the synchronized clock is same as free-run system clock. Therefore, accurate two-way delay measurements are possible. However, one-way delay measurements can result in unexpected values.

  • When NTP is enabled in the system, the synchronized clock is derived by the NTP clock.

  • When PTP is enabled in the system, the synchronized clock is derived by PTP clock.

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. See the 7210 SAS-D, Dxp, K 2F1C2T, K 2F6C4T, K 3SFP+ 8C 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:

• administrative MEP shut down

• port admin down

• port link down

• eth-bn no receive transitioning the ETH-BN function to disable

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.

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 about the eth-bn-egress-rate-changes command, see the 7210 SAS-D, Dxp, K 2F1C2T, K 2F6C4T, K 3SFP+ 8C 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.

The 7210 SAS supports port-based MEPs for use with CFM ETH-BN. The port MEP must be configured at level 0 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. No other CFM and Y.1731 messages are supported on these port-based MEPs.

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

tools dump eth-cfm top-active-meps
Calculating most active MEPs in both direction without clear ...

MEP                  Rx Stats     Tx Stats     Total Stats
-------------------- ------------ ------------ ------------
12/4/28              3504497      296649       3801146
14/1/28              171544       85775        257319
14/2/28              150942       79990        230932

tools dump eth-cfm top-active-meps clear
Calculating most active MEPs in both direction with clear ...

MEP                  Rx Stats     Tx Stats     Total Stats
-------------------- ------------ ------------ ------------
12/4/28              3504582      296656       3801238
14/1/28              171558       85782        257340
14/2/28              150949       79997        230946

tools dump eth-cfm top-active-meps clear
Calculating most active MEPs in both direction with clear ...

MEP                  Rx Stats     Tx Stats     Total Stats
-------------------- ------------ ------------ ------------
12/4/28              28           2            30
14/1/28              5            2            7
14/2/28              3            2            5 

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

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 multi-point 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. Nokia has implemented the required counters to determine loss in each direction. To correctly use the information that is gathered the following terms are defined:

• count

  The count is the number of probes that are sent when the last frame is not lost. When the last frames is or are lost, the count and unacknowledged equals the number of probes sent.

• out-loss (far-end)

  Out-loss packets are lost on the way to the remote node, from test initiator to the test destination.

• in-loss (near-end)

  In-loss packets are lost on the way back from the remote node to the test initiator.

• unacknowledged

  Unacknowledged packets are the number of packets at the end of the test that were not responded to.

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.

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.

The following are ETH-CFM configuration guidelines:

• The 7210 SAS platforms support only ingress MIPs in some services or bidirectional MIPs (that is, ingress and egress MIPs) in some services. ETH-CFM support matrix for 7210 SAS-D, ETH-CFM support matrix for 7210 SAS-Dxp, ETH-CFM support matrix for 7210 SAS-K 2F1C2T, ETH-CFM support matrix for 7210 SAS-K 2F6C4T, and ETH-CFM support matrix for 7210 SAS-K 3SFP+ 8C list the MIP and MEP support for different services on different platforms.

• On the 7210 SAS-D and 7210 SAS-Dxp, Up MEPs cannot be created by default on system bootup. Before Up MEPs can be created, the user must first use the commands in the following context to explicitly allocate hardware resources for use with this feature.

  configure system resource-profile

  The software will reject the configuration to create an Up MEP and generate an error until resources are allocated. See the 7210 SAS-D, Dxp, K 2F1C2T, K 2F6C4T, K 3SFP+ 8C Basic System Configuration Guide for more information.

• On the 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, and 7210 SAS-K 3SFP+ 8C, no explicit resource allocation is required before configuring Up MEPs.

• On the 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, and 7210 SAS-K 3SFP+ 8C, all MIPs are bidirectional. A MIP responds to OAM messages that are received from the wire and also responds to OAM messages that are being sent out to the wire. MIP support for SAP, SDP bindings, and services varies. See the 7210 SAS-D, Dxp, K 2F1C2T, K 2F6C4T, K 3SFP+ 8C Services Guide for more information.

• On 7210 SAS platforms, Ethernet Linktrace Response (ETH-LTR) is always sent out with priority 7.

• 7210 SAS platforms send out all CFM packets as in-profile. Currently, there is no mechanism in the SAA tools to specify the profile of the packet.

  This behavior is applicable to all 7210 SAS platforms where the feature supported has been added in both access-uplink mode and network mode of operation. See the 7210 SAS Software Release Notes 24.x.Rx for more information about which platform and MEPs or MIPs support this feature.

• To enable DMM version 1 message processing on the 7210 SAS-D (access-uplink mode) and 7210 SAS-Dxp (access-uplink mode) platforms, the following command must be used.

  configure eth-cfm system enable-dmm-version-interop

• To achieve better scaling on the 7210 SAS-D and 7210 SAS-Dxp, Nokia recommends that the MEPs are configured at specific levels. The recommended levels are 0, 1, 3, and 7.

• Ethernet rings are not configurable under all service types. Any service restrictions for the MEP direction or MIP support will override the generic capability of the Ethernet ring MPs. For more information about Ethernet rings, see the 7210 SAS-D, Dxp, K 2F1C2T, K 2F6C4T, K 3SFP+ 8C Interface Configuration Guide.

• The supported minimum CCM transmission interval values vary depending on the MEP type and 7210 SAS platform. The following table lists the supported minimum CCM timer values.

  Table 8. Minimum CCM transmission interval value support by 7210 SAS platform

  Platform	G.8032 down MEP	Service down MEP	Service up MEP
  7210 SAS-D	100 ms	100 ms	1 s
  7210 SAS-Dxp	10 ms	1 s	1 s
  7210 SAS-K 2F1C2T	10 ms	1 s	1 s
  7210 SAS-K 2F6C4T	10 ms	1 s	1 s
  7210 SAS-K 3SFP+ 8C	10 ms	1 s	1 s

• Sender-ID TLV processing is supported only for service MEPs. It is not supported for G.8032 MEPs.

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:

• DefRDICCM

• DefMACstatus

• DefRemoteCCM

• DefErrorCCM

• DefXconCCM

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

• reception of AIS for the local MEP level

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.

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:

• generating AIS for specific MEP levels

• sending CCM with interface status TLV ‟down”

• stopping CCM transmission

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.

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.

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.

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.

Fault propagation allows the user to track an Epipe service link connectivity failure and propagate the failure toward customer devices connected to access ports.

The following figure shows an example Epipe service architecture.

In the preceding figure, the 7210 SAS node is deployed as the network interface device (NID) and the customer premises equipment (CPE) is connected to the 7210 SAS over a dot1q SAP (may be a single VLAN ID dot1q SAP, range dot1q SAP, or default dot1q SAP). The 7210 SAS adds an S-tag to the packet received from the customer, and the packet is transported over the backhaul network to the service edge, which is typically a 7750 SR node acting as an external network-to-network interface (ENNI) where the service provider (SP) is connected. At the ENNI, the 7750 SR hands off the service to the SP over a SAP.

Service availability must be tracked end-to-end between the uplink on the 7210 SAS and the customer hand-off point. If there is a failure or a fault in the service, the access port toward the SP is brought down. For this reason, a Down MEP is configured on the 7210 SAS access-uplink SAP facing the network, or alternatively, an Up MEP can be configured on the access port connected to the CPE. The Down MEP has a CFM session with a remote Up MEP configured on the SAP facing the SP node that is the service hand-off point toward the SP. The customer-facing access port and the access-uplink or access SAP facing the network with the Down MEP are configured in an Epipe service on the 7210 SAS.

Connectivity fault management (CFM) continuity check messages (CCMs) are enabled on the Down MEP and used to track end-to-end availability. On detection of a fault that is higher than the lowest-priority defect of the configured MEP, the access port facing the customer is brought down (with the port tx-off action), which immediately indicates the failure to the CPE device connected to the 7210 SAS and allows the node to switch to another uplink, if available.

To enable fault propagation from the access-uplink SAP to the access port, the user can configure an operational group using the defect-oper-group command. An operational group configured on a service object (the CFM MEP on the Epipe SAP in this use case) inherits the operational status of that service object and on change in the operational state notifies the service object that is monitoring its operational state. The user can configure monitoring using the monitor-oper-group command under the service object (the access port connected to the customer in this use case).

For this use case, the user can configure an operational group under the CFM MEP to track the CMF MEP fault status so that when the CFM MEP reports a fault, the corresponding access ports that are monitoring the CFM MEP state is brought down (by switching off the laser on the port, similar to link loss forwarding (LLF)). When the CFM MEP fault is cleared, the operational group must notify the service object monitoring the MEP (that is, the access port) so that the access port can be brought up (by switching on the laser on the port, similar to LLF). The user can use the low-priority-defect command to configure the CFM session events that cause the MEP to enter the fault state.

If the MEP reports a fault greater than the configured low-priority defect, the software brings down the operational group so that the port configured to monitor that operational group becomes operationally down. After the MEP fault is cleared (that is, the MEP reports a fault lower than the configured low-priority defect), the software brings up the operational group so that the port monitoring the operational group becomes operationally up.

Fault detection is supported in only one direction from the MEP toward the other service endpoint. The fault is propagated in the opposite direction from the MEP toward the access port. Fault detection and propagation must not be configured in the other direction.

In the 7210 SAS, for various applications, such as IP traceroute, control CPU inserts the timestamp in software.

When interpreting these timestamps care must be taken that some nodes are not capable of providing timestamps, therefore timestamps must be associated with the same IP-address that is being returned to the originator to indicate what hop is being measured.

Because NTP precision can vary (+/- 1.5ms between nodes even under best case conditions), SAA one-way latency measurements may display negative values, especially when testing network segments with very low latencies. The one-way time measurement relies on the accuracy of NTP between the sending and responding nodes.

Loopback (LBM), linktrace (LTR) and two-way-delay measurements (Y.1731 ETH-DMM) can be scheduled using SAA. Additional timestamping is required for non Y.1731 delay-measurement tests, to be specific, loopback and linktrace tests. An organization-specific TLV is used on both sender and receiver nodes to carry the timestamp information. Currently, timestamps are only applied by the sender node. This means any time measurements resulting from loopback and linktrace tests includes the packet processing time of the remote node. Because Y.1731 ETH-DMM uses a four time stamp approach to remove the remote processing time it should be used for accurate delay measurements.

The SAA versions of the CFM loopback, linktrace and ETH-DMM tests support send-count, interval, timeout, and FC. The existing CFM OAM commands have not been extended to support send-count and interval natively. The summary of the test results are stored in an accounting file that is specified in the SAA accounting-policy.

SAA statistics enables writing statistics to an accounting file. When results are calculated an accounting record is generated.

To write the SAA results to an accounting file in a compressed XML format at the termination of every test, the results must be collected, and, in addition to creating the entry in the appropriate MIB table for this SAA test, a record must be generated in the appropriate accounting file.

This section describes the prerequisites a user must be aware of before using the testhead OAM tool. It is divided into three sections. First, the generic prerequisites applicable to all 7210 SAS platforms are listed, followed by prerequisites specific to the 7210 SAS-D and 7210 SAS-Dxp platforms, and then followed by prerequisites specific to the 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, and 7210 SAS-K 3SFP+ 8C.

These sections are applicable to both the testhead tool and service testhead tool. The service testhead tool may have additional prerequisites which are described in the following section.

The 7210 SAS-Dxp, 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, and 7210 SAS-K 3SFP+ 8C support the service test framework through the use of the service test testhead OAM tool. This tool allows for configuration of multiple streams (also called flows) for which service performance metrics can be obtained. See the Platform Scaling Guide to know the number of streams supported by the various platforms. With multiple streams, it is possible to configure one or more service tests to validate one or more services each with one or more forwarding classes (FCs), or validate a single service with one or more FCs, or validate a mix of a number of services and FCs as long as the number of streams are within the limit supported by the platform.

A set of streams under a single service test can be grouped together using the service-stream configuration commands and each stream can be configured with the options listed as follows:

• The CIR and/or PIR can be configured for each of the streams, along with the frame payload contents and the frame size.

• Different acceptance criteria per stream can be configured and used to determine pass/fail criteria for the stream, along with the ability to monitor the streams that are in progress.

• For each stream, it is possible to use a single command to run a service configuration test, CIR test, PIR test, and service performance test concurrently instead of running each test individually.

• Instead of using threshold parameters to determine the pass/fail criteria for a test, it is possible configure the margin by which the measured throughput is off from the configured throughput to determine pass/fail criteria. The margin is configured using the use-m-factor CLI command.

The test results can be stored in an accounting record in XML format. The XML file contains the keywords and MIB references listed in the following table.

This section lists the configuration guidelines for the testhead OAM tool and the service testhead OAM tool, unless indicated otherwise. These guidelines apply to all 7210 SAS platforms described in this guide unless a specific platform is called out explicitly.

• SAPs configured on LAG cannot be configured for testing with testhead tool. Other than the test SAP, other service endpoints (For example: SAPs/SDP-Bindings) configured in the service can be over a LAG.

• On the 7210 SAS-D, software automatically assigns the resources associated with internal ports for use with the testhhead tool.

• On the 7210 SAS-D, testhead OAM tool uses internal loopback ports. On the 7210 SAS-Dxp, the user can assign the resources of an internal loopback port to the testhead OAM tool or port loopback with MAC swap. Depending on the throughput being validated, either a 1GE internal loopback port or 10GE internal loopback port can be used.

• On the 7210 SAS-D and 7210 SAS-Dxp, port loopback with MAC swap is used at both ends and all services on the port on which the test SAP is configured and SAPs in the VPLS service, other than the test SAP should be shutdown or should not receive any traffic.

• The configured CIR/PIR is rounded off to the nearest available hardware rates. User is provided with an option to select the adaptation rule to use (similar to support available for QoS policies).

• On the 7210 SAS-D and 7210 SAS-Dxp, the FC specified is used to determine the queue to enqueue the marker packets generated by testhead application on the egress of the test SAP on the local node.

• On the 7210 SAS-Dxp and 7210 SAS-K 3SFP+ 8C, the testhead OAM tool allows validation of speeds up to approximately 10 Gb/s.

• ITU-T Y.1564 recommends to provide an option to configure the CIR step-size and the step-duration for the service configuration tests. This is not supported directly in 7210 SAS. It can be achieved by the NSP NFM-P or a third-party NMS system or an application with configuration of the desired rate and duration to correspond to the CIR step-size and step duration and repeating the test a second time, with a different value of the rate (that is, CIR step size) and duration (that is, step duration) and so on.

• Testhead waits for about 5 seconds at the end of the configured test duration before collecting statistics. This allows for all in-flight packets to be received by the node and accounted for in the test measurements. User cannot start another test during this period.

• When using testhead to test bandwidth available between SAPs configured in a VPLS service, operators must ensure that no other SAPs in the VPLS service are exchanging any traffic, particularly BUM traffic and unicast traffic destined for either the local test SAP or the remote SAP. BUM traffic eats into the network resources which is also used by testhead traffic.

• It is possible that test packets (both data and/or marker packets) remain in the loop created for testing when the tests are stopped. This is highly probable when using QoS policies with much lower shaper rate values, resulting in high latency for packets flowing through the network loop. User must remove the loop at both ends when the test is complete or when the test is stopped and wait for a suitable interval before starting the next test for the same service, to ensure that packets drain out of the network for that service. If this is not done, then the subsequent tests might process and account these stale packets, resulting in incorrect results. Software cannot detect stale packets in the loop as it does not associate or check each and every packet with a test session.

• Traffic received from the remote node and looped back into the test port (where the test SAP is configured) on the local end (that is, the end where the testhead tool is invoked) is dropped by hardware after processing (and is not sent back to the remote end). The SAP ingress QoS policies and SAP ingress filter policies must match the packet header fields specified by the user in the testhead profile, except that the source/destination MAC addresses are swapped.

• On the 7210 SAS-D and 7210 SAS-Dxp, latency is not be computed if marker packets are not received by the local node where the test is generated and printed as 0 (zero), in such cases. If jitter = 0 and latency > 0, it means that jitter calculated is less than the precision used for measurement. There is also a small chance that jitter was not actually calculated, that is, only one value of latency has been computed. This typically indicates a network issue, instead of a testhead issue.

• When the throughput is not met, FLR cannot be calculated. If the measured throughput is approximately +/-10% of the user configured rate, FLR value is displayed; else software prints ‟Not Applicable”. The percentage of variance of measured bandwidth depends on the packet size in use and the configured rate.

• On the 7210 SAS-D and 7210 SAS-Dxp, the user must not use the CLI command to clear statistics of the test SAP port, testhead loopback port and MAC swap loopback port when the testhead tool is running. The port statistics are used by the tool to determine the Tx/Rx frame count.

• On the 7210 SAS-D and 7210 SAS-Dxp, the testhead tool generates traffic at a rate slightly above the CIR. The additional bandwidth is attributable to the marker packets used for latency measurements. This is not expected to affect the latency measurement or the test results in a significant way.

• If the operational throughput is 1kb/s and it is achieved in the test loop, the throughput computed could still be printed as 0 if it is < 1Kb/s (0.99 kb/s, for example). Under such cases, if FLR is PASS, the tool indicates that the throughput has been achieved.

• The testhead tool displays a failure result if the received count of frames is less than the injected count of frames, even though the FLR may be displayed as 0. This happens because of truncation of FLR results to 6 decimal places and can happen when the loss is very less.

• On the 7210 SAS-D and 7210 SAS-Dxp, as the rate approaches the maximum rate supported on the platform or the maximum rate of the loop (which includes the capacities of the internal loopback ports in use), the user needs to account for the marker packet rate and the meter behavior while configuring the CIR. In other words, if the user needs to test 1 Gb/s for a frame size of 512 bytes, then they will need to configure about 962396 Kb/s, instead of 962406 Kb/s, the maximum rate that can be achieved for this frame size. In general, they would need to configure about 98% to 99% (based on packet size) of the maximum possible rate to account for marker packets when they need to test at rates which are closer to the bandwidth available in the network. The reason for this is that at the maximum rate injection of marker packets by CPU will result in drops of either the injected data traffic or the marker packets themselves, as the net rate exceeds the capacity. These drops cause the testhead to always report a failure, unless the rate is marginally reduced.

• The testhead uses the Layer 2 rate, which is calculated by subtracting the Layer 1 overhead that is caused when the IFG and Preamble are added to every Ethernet frame (typically about 20 bytes (IFG = 12 bytes and Preamble = 8 bytes)). The testhead tool uses the user-configured frame size to compute the Layer 2 rate and does not allow the user to configure a value greater than that rate. For 512-byte Ethernet frames, the L2 rate is 962406 Kb/s and the Layer 1 rate is 1 Gb/s.

• It is not expected that the operator will use the testhead tool to measure the throughput or other performance parameters of the network during the course of network event. The network events could be affecting the other SAP/SDP-Binding/PW configured in the service. Examples are transition of a SAP because of G8032 ring failure, transition of active/ standby SDP-Binding/PW because of link or node failures.

• On the 7210 SAS-D and 7210 SAS-Dxp, the 2-way delay (also known as latency) values measured by the testhead tool are more accurate than those obtained using OAM tools, as the timestamps are generated in hardware.

• On the 7210 SAS-D and 7210 SAS-Dxp, the profile assigned to the packets generated by the testhead is ignored on access SAP ingress. 7210 SAS service access port, access-uplink port, or network port can mark the packets appropriately on egress to allow the subsequent nodes in the network to differentiate the in-profile and out-of-profile packets and provide them with appropriate QoS treatment. 7210 SAS access-uplink ingress and network port ingress is capable of providing appropriate QoS treatment to in-profile and out-of-profile packets.

• On the 7210 SAS-D and 7210 SAS-Dxp, the marker packets are sent over and above the configured CIR or PIR. The tool cannot determine the number of green packets injected and the number of yellow packets injected individually. Therefore, marker packets are not accounted for in the injected or received green or in-profile and yellow or out-of-profile packet counts. They are only accounted for in the Total Injected and the Total Received counts. So, the FLR metric accounts for marker packet loss (if any), while green or yellow FLR metric does not account for any marker packet loss.

• On the 7210 SAS-D and 7210 SAS-Dxp, marker packets are used to measure green or in-profile packets latency and jitter and the yellow or out-of-profile packets latency and jitter. These marker packets are identified as green or yellow based on the packet marking (for example, dot1p). The latency values can be different for green and yellow packets based on the treatment provided to the packets by the network QoS configuration.

• On the 7210 SAS-Dxp, to configure tests with multiple streams, use the config>test-oam>testhead-num-streams multiple command. This command must be executed both on the local (testhead generator end) and on the remote end (testhead reflector end) when the multiple stream mode is in use. When multiple stream mode is configured, the user must ensure that no traffic other than testhead traffic is being used by the stream on both the reflector and generator side in the services. In this mode, the software programs a different datapath that restricts the usage of flows other than test streams in the same service as the SAP to which the streams belongs. This command is stored across a reboot.

• On the 7210 SAS-Dxp, to configure tests with multiple streams, each stream must be specified and configured with the config>test-oam>loopback entry entry-id internal port port-id service service-id sap sap-id src-mac ieee-address dst-mac ieee-address command. This loopback entry commands is not stored across a reboot in the configuration file. The traffic streams are identified by the source MAC address and destination MAC address (regardless of traffic streams belonging to the same SAP/service or a different SAP/service and regardless of the type of service Epipe or VPLS).

• On the 7210 SAS-Dxp with the service test testhead tool, each stream must use a distinct source MAC and destination MAC. In other words, the source MAC and destination MAC address must not be repeated across the streams.

• On the 7210 SAS-Dxp with the service test testhead tool, the static MAC address must be configured in the VPLS for both the source MAC and destination MAC address used for each of the streams.

• On the 7210 SAS-Dxp, the DEI configuration with vlan-tag-1 and vlan-tag-2 is not supported.

• On the 7210 SAS-Dxp, while vaidating with multiple streams, the sum of all the streams must not exceed 99% of 1 Gb/s or 10 Gb/s (based on MAC swap loopback bandwidth).

• On the 7210 SAS-Dxp with the service test testhead tool, a stream can be configured with a fixed frame size. Each stream that makes up a service test can be configured with a different frame size. A mix of different frame sizes per stream is not allowed.

• On the 7210 SAS-Dxp with the service test testhead tool, only one service test can be run at a given point of time. One service test can be configured for different SAPs from different services, or the same SAPs with different FCs, or a mix of SAPs and FCs.

• On the 7210 SAS-Dxp with the service test testhead tool, both the endpoints of the Epipe must be configured before a loopback entry is configured. This restriction does not apply to a VPLS.

• On the 7210 SAS-Dxp, a test duration of less than three minutes is not allowed to run a testhead session.

• On the 7210 SAS-Dxp configured with svc-sap-type, dot1q-range, and null-star, for particular VPLS services there can only be one test SAP (on that test SAP there can be one to four streams, but there cannot be a different SAP as part of same VPLS service, there can be different VPLS services to use for different test SAPs). This does not apply to VPLS services configured with svc-sap-type any.

• On the 7210 SAS-Dxp, the service test testhead OAM tool computes the operational rate based on the user-configured rate by deducting the metadata overhead of eight bytes added in the datapath. The additional eight bytes are required to maintain state information about the streams across the MAC swap loopback port.

• It is recommended that users should configure the config>test-oam>acceptance-criteria>use-m-factor value to account for latency packets that are generated over and above the configured CIR or PIR rate.

• When test-type policing is used, the testhead tool generates traffic at a 125% line rate. To account for the line rate, configure a maximum PIR rate less than 79% to 80% of maximum speed of the port on which the test SAP is configured.

• The following table describes SAP encapsulations that are supported for single-stream service testhead on 7210 SAS-D and 7210 SAS-Dxp.

  Table 12. SAP encapsulations supported for single-stream service testhead on 7210 SAS-D and 7210 SAS-Dxp

  Epipe service configured with svc-sap-type	Test SAP encapsulations
  null-star	Null, :*, 0.*, Q.*
  Any	Null , :0 , :Q , :Q1.Q2
  dot1q-preserve4, dot1q-range	:Q

  ¹ dot1q-preserve is supported for testhead OAM tool. It is not supported for the service test testhead OAM tool.

• The following table describes SAP encapsulations that are supported for multi-stream service testhead on 7210 SAS-D and 7210 SAS-Dxp.

  Table 13. SAP encapsulations supported for multi-stream service testhead on 7210 SAS-D and 7210 SAS-Dxp

  Epipe service configured with svc-sap-type	Test SAP encapsulations
  null-star	Null, :*
  Any	Null , :0 , :Q , :Q1.Q2
  dot1q-preserve4, dot1q-range	:Q

7210 SAS devices support port loopback for Ethernet ports. There are two types of port loopback commands: port loopback without MAC swap and port loopback with MAC swap. Both these commands are helpful for testing the service configuration and measuring performance parameters such as throughput, delay, and jitter on service turn-up. Typically, a third-party external test device is used to inject packets at desired rate into the service at a central office location. For more information about port loop back functionality, see the 7210 SAS-D, Dxp, K 2F1C2T, K 2F6C4T, K 3SFP+ 8C Interface Configuration Guide.

Per-SAP loopback with MAC swap is is useful for testing the service configuration and measuring performance parameters such as throughput, delay, and jitter on service turn-up. Typically, the testhead OAM tool is used to inject packets at a desired rate into the service from the remote site. It is also possible to use a third-party external test device to inject packets at a desired rate into the service at a central office location. For more information about SAP loopback functionality, see the 7210 SAS-D, Dxp, K 2F1C2T, K 2F6C4T, K 3SFP+ 8C Services Guide.

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:

• session type

  The session type is the impetus of the test, which is either proactive (default) or on-demand. Individual test timing parameters are influenced by this setting. A proactive session will start immediately following the execution of a no shutdown command for the test. A proactive test will continue to execute until a manual shutdown stops the individual test. On-demand tests will also start immediately following the no shutdown command. However, the operator can override the no test-duration default and configure a fixed amount of time that the test will execute, up to 24 hours (86400 seconds). If an on-demand test is configured with a test-duration, it is important to shut down tests when they are completed. In the event of a high availability event causing the backup CPM to become the active CPM, all on-demand tests that have a test-duration statement will restart and run for the configured amount of time regardless of their progress on the previously active CPM.

• test family

  The test family is the main branch of testing that addresses a specific technology. The available test for the session are based on the test family. The destination, source, and priority are common to all tests under the session and are defined separately from the individual test parameters.

• test parameters

  Test parameters are included in individual tests, as well as the associated parameters including start and stop times and the ability to activate and deactivate the individual test.

• measurement interval

  A measurement interval is the assignment of collection windows to the session with the appropriate configuration parameters and accounting policy for that specific 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.

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:

• the Flag Field (1 bit – LSB) is defined as the Type (Proactive=1 | On-Demand=0)

• the test ID TLV (32 bits) is carried in the Optional TLV portion of the PDU

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 test ID as part of the test parameters, which uniquely identifies the test within the specific protocol. A test ID 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 test ID because they are different protocols. However, if a test ID 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 test ID 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 test ID, Source MAC, and Destination MAC are used to maintain the uniqueness of the responder. This means that the test ID has only local, and not global, significance.

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. Because of 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 listed 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:

• Time of day clock is adjusted by more than 10 seconds

• Test start does not align with the start boundary of the measurement interval. This would be common for the first execution for clock aligned tests.

• Test stopped before the end of the measurement interval boundary

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.

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:

• Frame Delay (FD)

  FD is the amount of time required to send and receive the packet.

• InterFrame Delay Variation (IFDV)

  IFDV is the difference in the delay metrics between two adjacent packets.

• Frame Delay Range (FDR)

  FDR is the difference between the minimum frame delay and the individual packet.

• Mean Frame Delay (MFD)

  MFD is the mathematical average for the frame delay over the entire window.

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.

Evaluating and computing loss and availability 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 therefore 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.

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 taken when configuring 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:

-------------------------------------------------------------------------------
Configured Lower Bounds for Delay Measurement (DMM) Tests, in microseconds
-------------------------------------------------------------------------------
Group Description                    Admin Bin     FD(us)    FDR(us)   IFDV(us)
-------------------------------------------------------------------------------
1     OAM PM default bin group (not*    Up   0          0          0          0
                                             1       5000       5000       5000
                                             2      10000          -          -
-------------------------------------------------------------------------------

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.

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