Y.1564 testhead OAM tool (2024)

The 7210SASprovides support for both the original Y.1564 testhead OAM tool implementation and an enhancedimplementation of the tool, referred to as the service test testhead OAM tool. The 7210SAS-Dsupports only the original Y.1564 testhead OAM tool implementation. The 7210SAS-K 2F1C2Tand 7210SAS-K 2F6C4Tsupport both the original and the enhanced implementations. The 7210SAS-K 3SFP+ 8Csupports only the enhanced implementations. For information about the enhanced implementation,see Service test testhead OAM Tool for the 7210SAS-K 2F1C2T, 7210SAS-K 2F6C4T, and 7210SAS-K 3SFP+ 8C.

Note:

  • Port loopback with MAC swap and the Y.1564 testhead OAM tool is only supported on the 7210SAS-D and 7210SAS-Dxp, and only for Epipe and VPLS services.

  • Per-SAP loopback with MAC swap and the Y.1564 testhead OAM tool is supported on the 7210SAS-K 2F1C2T, 7210SAS-K 2F6C4T, and 7210SAS-K 3SFP+ 8C, and only for Epipe and VPLS services. Port loopback with MAC swap is not supported on these platforms.

ITU-T Y.1564 defines the out-of-service test methodology to be used and parameters to be measured to test service SLA conformance during service turn up. It primarily defines two test phases. The first test phase defines the service configuration test, which consists of validating whether the service is configured correctly. As part of this test the throughput, frame delay, frame delay variation (FDV), and frame loss ratio (FLR) is measured for each service. This test is typically run for a short duration. The second test phase consists of validating the quality of services delivered to the end customer and is referred to as the service performance test. These tests are typically run for a longer duration. All traffic is generated up to the configured rate for all the services simultaneously and the service performance parameters are measured for each service.

The 7210SASsupports the service configuration test for a user-configured rate and measurement of delay,delay variation, and frame loss ratio with the testhead OAM tool. The testhead OAM toolsupports bidirectional measurement. On the 7210SAS-D,the testhead OAM tool can generate test traffic for only one service at a specific time. Onthe 7210SAS-K 2F1C2Tand 7210SAS-K 2F6C4T,the testhead OAM tool can generate test traffic for up to four services simultaneously. On the7210SAS-K 3SFP+ 8C,the testhead OAM tool can generate test traffic for up to eight streams or servicessimultaneously. The tool validates if the user-specified rate is available and computes thedelay, delay variation, and frame loss ratio for the service under test at the specified rate.The tool is capable of generating traffic at a rate of up to 1 Gb/s on the 7210SAS-D,7210SAS-K 2F1C2T, and 7210SAS-K 2F6C4T.The tool is capable of generating traffic at a rate of up to approximately 10 Gb/s on the 7210SAS-Dxpand 7210SAS-K 3SFP+ 8C.On some 7210SASdevices, the resources needed for this feature must be configured on the front-panel port; onother 7210SASdevices, the resources needed for this feature are automatically allocated by software fromthe internal ports. See Configuration guidelines forinformation about which 7210SASplatforms need user configuration.

The following figure shows the remote loopback required and the flow of the frame through the network generated by the testhead tool.

The tool allows the user to specify the frame payload header parameters independent of the testSAP configuration parameters. This capability gives the user flexibility to test for differentpossible frame header encapsulations. The user can specify the appropriate VLAN tags,Ethertype, and Dot1p values independent of the SAP configuration like with actual servicetesting. In other words, the software does not use the parameters (For example: SAP ID, SourceMAC, and Destination MAC) during the invocation of the testhead tool to build the test frames.Instead it uses only the parameters specified in the frame-payload CLIcommand. The software does not verify that the parameters specified match the serviceconfiguration used for testing, for example, software does not match if the VLAN tagsspecified matches the SAP tags, the Ethertype specified matches the user configured portEthertype, and so on. It is expected that the user configures theframe-payload appropriately so that the traffic matches the SAPconfiguration.

7210SAS-D and 7210SAS-Dxp support Y.1564 testhead for performing CIR or PIR tests for both color-blind mode and color-aware mode. In color-aware mode, users can perform service turn-up tests to validate the performance characteristics (delay, jitter, and loss) for committed rate (CIR) and excess rate above CIR (that is, PIR rate). The testhead OAM tool uses the in-profile packet marking value and out-of-profile packet marking value to differentiate between committed traffic and PIR traffic in excess of CIR traffic. Traffic within CIR (that is, committed traffic) is expected to be treated as in-profile traffic in the network and traffic in excess of CIR (that is, PIR traffic) is expected to be treated as out-of-profile traffic in the network, allowing the network to prioritize committed traffic over PIR traffic. The testhead OAM tool allows the user to configure individual thresholds for green or in-profile packets and out-of-profile or yellow packets. It is used by the testheadOAM tool to compare the measured value for green or in-profile packets and out-of-profile or yellow packets against the configured thresholds and report success or failure.

Note:

CIR and PIR tests in color-aware mode are only supported on the 7210SAS-D and 7210SAS-Dxp.

The 7210SAS testhead OAM tool supports the following functionality:

  • Supports configuration of only access SAPs as the test measurement point.

  • Supports all port encapsulations on all service SAP types, with some exceptions as indicated in the following Configuration guidelines.

  • Supported for SAPs configured for VPLS and Epipe service. SAPs configured for other services are not supported.

  • Supports two-way measurement of service performance metrics. The tests measure throughput, frame delay, frame delay variation, and frame loss ratio.

  • On the 7210SAS-D and 7210SAS-Dxp, for two-way measurement of the service performance metrics such as frame delay and frame delay variation, test frames (also known as marker packets) are injected into the test flow at a low rate at periodic intervals. Frame delay and frame delay variation is computed for these frames. On the 7210SAS-K 2F1C2T, 7210SAS-K 2F6C4T, and 7210SAS-K 3SFP+ 8C, there are no separate marker packets used for delay measurements. Instead, samples of the test traffic are used for measuring the delay. Hardware-based timestamps are used for delay computation.

  • The 7210SAS supports configuration of a rate value and provides an option to measure performance metrics. The testhead OAM tool generates traffic up to the specified rate and measures service performance metrics such as delay, jitter, loss for in-profile traffic, and out-of-profile traffic.

  • The testhead tool can generate traffic at a maximum rate of 1 Gb/s on the 7210SAS-D, 7210SAS-K 2F1C2T, and 7210SAS-K 2F6C4T. The testhead tool can generate traffic at a maximum rate of approximately 10 Gb/s on the 7210SAS-Dxp and 7210SAS-K 3SFP+ 8C. The CIR and PIR can be specified by the user. These rates are rounded off to the nearest hardware-supported rate by using the adaptation rule configured by the user.

  • Allows the user to specify a frame size ranging from 64 bytes to 9212 bytes. Only a single frame size can be specified.

  • The user can configure the following frame payload types: L2 payload, IP payload, and IP/TCP/UDP payload. The testhead tool uses these configured values for the IP header fields and TCP header fields in the generated frames. The user can optionally specify the data pattern to use in the payload field of the frame/packet.

  • Allows the user to configure the duration of the test up to a maximum of 24 hours, 60 minutes, and 60 seconds. The test performance measurements are done after the specified rate is achieved. At any time user can probe the system to know the current status and progress of the test.

  • Supports configuration of the Forwarding Class (FC). It is expected that user will define consistent QoS classification policies to map the packet header fields to the FC configured on the test SAP ingress on the local node, in the network on the nodes through which the service transits, and on the SAP ingress in the remote node.

  • On the 7210SAS-D, 7210SAS-K 2F1C2T, and 7210SAS-K 2F6C4T, the user can use the testhead tool to configure a test profile, also known as a policy template, that defines the test configuration parameters. The user can start a test using a preconfigured test policy for a specific SAP and service. The test profile allows the user to configure the acceptance criteria. The acceptance criteria allows user to configure the thresholds that indicates the acceptable range for the service performance metrics. For more information, see Configuring testhead tool parameters. An event is generated if the test results exceed the configured thresholds. At the end of the test, the measured values for frame delay (FD), frame delay variation (FDV), and frame loss ratio (FLR) are compared against the configured thresholds to determine the pass or fail criteria and to generate a trap to the management station. If the acceptance criteria are not configured, the test result is declared to bepass if the throughput is achieved and frame loss is 0 (zero).

  • ITU-T Y.1564 specifies the following tests:

    • service configuration tests

      Short duration tests used to check if the configuration is correct and can meet requested SLA metrics such as throughput, delay, and loss:

      • CIR configuration test (color-aware and non-color aware)

      • PIR configuration test (color-aware and non-color aware)

      • traffic policing test (color-aware and non-color aware)

    • service performance test

      Long duration test used to check the service performance metrics.

    Service configuration tests can be run by setting the rate value appropriately for the specific test. For example, traffic policing tests can be executed by specifying a PIR to be 125% of the desired PIR. A traffic policing test can be executed in either color-aware mode or color-blind (non-color-aware) mode. The 7210SAS-D and 7210SAS-Dxp support both color-aware and color-blind mode. The 7210SAS-K 2F1C2T and 7210SAS-K 2F6C4T support color-blind mode only. The 7210SAS-K 3SFP+ 8C supports color-blind mode only using the service test testhead OAM tool.

  • ITU-T Y.1564 specifies separate test methodology for color-aware and non-color-aware tests. Thestandard requires a single test to provide the capability to generate bothgreen-color/in-profile traffic for rates within CIR and yellow-color or out-of-profiletraffic for rates above CIR and within EIR. Because SAP ingress does not supportcolor-aware metering, it is not possible to support EIR color-aware and traffic policingcolor-aware tests end-to-end in a network (that is, from test SAP to test SAP). Instead,It is possible to use the tests to measure the performance parameters from the otherendpoint (example Access-uplink SAP) in the service, through the network, to the remotetest SAP, and back again to the local test SAP.

Y.1564 testhead OAM tool (2024)

References

Top Articles
Latest Posts
Article information

Author: Ouida Strosin DO

Last Updated:

Views: 5322

Rating: 4.6 / 5 (56 voted)

Reviews: 87% of readers found this page helpful

Author information

Name: Ouida Strosin DO

Birthday: 1995-04-27

Address: Suite 927 930 Kilback Radial, Candidaville, TN 87795

Phone: +8561498978366

Job: Legacy Manufacturing Specialist

Hobby: Singing, Mountain biking, Water sports, Water sports, Taxidermy, Polo, Pet

Introduction: My name is Ouida Strosin DO, I am a precious, combative, spotless, modern, spotless, beautiful, precious person who loves writing and wants to share my knowledge and understanding with you.