Y.1564 Ethernet Service Activation Test Configuration

We partially support the ITU-T Y.1564 standard in Junos OS Evolved. Y.1564 validates Ethernet service level agreement (SLA) parameters in a single test. You configure tests and services. The software produces a performance test report (PTR) with information rate, delay, and loss information.

Overview

ITU‑T Y.1564 is an Ethernet service activation test methodology designed to turn up, install, and troubleshoot Ethernet‑based services in operational networks. This methodology includes tests that you perform after service activation. These tests verify that a newly operational network service to be used by a customer is working properly before notifying the customer that the service is ready to be used. Unlike RFC 2544 benchmarking tests, a Y.1564 test verifies that an Ethernet service meets its agreed SLA. The Y.1564 test verifies the SLA by measuring the delivered performance across bandwidth profiles, color behavior, and acceptance criteria over defined durations. Use Y.1564 tests for service activation and SLA validation in operational networks. Reserve RFC 2544 tests for laboratory benchmarking of device limits; RFC 2544 benchmark tests do not validate end‑to‑end service delivery. See https://www.itu.int/rec/T-REC-Y.1564-201602-I/en to access the Y.1564 standard document and to learn more about how to configure and run Y.1564-compliant tests.

This feature enables you to configure a test with general settings and one or more services, and to generate a PTR. General settings include the measurement mode, test duration, direction (ingress or egress), and the interface used as the packet entry point. Each service includes a bandwidth profile, color mode, frame and flow identification, and service acceptance criteria (SAC). The PTR reports measured information rate (IR), frame transfer delay (FTD), and frame loss ratio (FLR).

We support round-trip measurements as shown in Figure 1.

Figure 1: Round-trip Y.1564 measurement

Benefits of Y.1564 Tests

Validates the complete SLA in one test, aligned with operational conditions rather than laboratory maximums.
Confirms bandwidth profile parameters—committed information rate (CIR), excess information rate (EIR), and color mode—so service turn‑up matches the contract.
Measures and reports IR, FTD, and FLR in the PTR for clear pass/fail assessment against the SAC.
Supports multi‑duration testing to capture time‑varying impairments typical of operational networks.
Provides color‑aware validation that maps CIR and EIR to CoS or differentiated services code point (DSCP) values for per‑color results.
Offers flexible setup: ingress or egress direction, and configurable durations from 1 minute to 24 hours.

Key Components

Test configuration—Defines general settings and the list of parameters to test (mode, duration, direction, and interface).
Service configuration—Defines the bandwidth profile steps (CIR, EIR, and traffic policing), color mode (color‑aware or color‑blind), frame pattern, flow identifiers, and the SAC.
Performance test report (PTR)—Summarizes measured IR, FTD, and FLR for each service and step, supporting pass/fail decisions against the SAC. The SAC are a set of criteria you configure to ensure that a service meets its functionality and quality requirements and that the service is ready for customers to use. You can see this report by issuing the show services monitoring y1564 command.

Limitations and Caveats

Y.1564 and RFC 2544 tests cannot run concurrently on the same interface. Schedule tests separately.
Only one Y.1564 test can run on an interface at a time. Each test supports testing for only one service. Start additional tests on other interfaces if required.
Platform and offload support can vary; verify supported hardware and software releases before scheduling a test. See Feature Explorer: ITU-T Y.1564 Ethernet Service Activation Test Methodology for supported platforms and releases.
When calculating IR, you need to account for the possibility of additional bandwidth because of interleaving FL-PDUs and FD-PDUs being sent simultaneously. See MEF 49: Service Activation Testing Control Protocol and PDU Formats, section "Interleaving FL-PDU and FD-PDU".
If the generation IR is ≤ 1 Mbps, we recommend setting step-duration to ≤ 4 seconds.
With some configurations of NNI interfaces, you cannot run the test with frame size less than 68 (include a in the emix statement). In such cases, we report an error when trying to run a test with frame size less than 68.
You cannot initiate Y.1564 tests on a Layer 3 interface or on an integrated routing and bridging (IRB) interface.
You cannot configure an interface on the initiator that is a logical interface that is a part of Ethernet-Tree (E-Tree), Virtual Extensible LAN (VXLAN), sFlow, or unicast RPF flow configurations.
Ingress filtering is based on the packet’s destination MAC address. Ensure test packets arriving at the device do not use a destination MAC address that matches any L2 ingress or egress Session ID.
Y.1564 tests support only single-homed topologies.
Delay metrics depend on the selected measurement mode and direction; choose modes that match your SLA.

Understand Test Direction

You can configure Y.1564 tests over EVPN services, including E-Line and E-LAN services. For these tests, you need to determine what direction (ingress or egress) you need to configure for the test, for both the initiator (generator) and the reflector. Figure 2 shows these directions:

Figure 2: Ingress and Egress Directions for Generation and Reflection

For the direction statement configured on the initiator:

With direction ingress set, the initiator generates traffic sourced from the user–network interface (UNI) interface. This traffic traverses the Packet Forwarding Engine for the Layer 2 (L2) service forwarding lookup, and the traffic goes through the network-to-network interface (NNI) interface toward the reflector. 
With direction egress set, the initiator generates traffic sourced from the NNI interface. The traffic travels directly outbound toward the reflector.

For the direction statement configured on the reflector:

With direction ingress set, the reflector reflects incoming packet directly at the NNI interface that receives the traffic, without any L2 service forwarding through the Packet Forwarding Engine.

With direction egress set, the reflector reflects traffic after the L2 service forwarding lookup but immediately before the UNI interface. The traffic travels instead toward the NNI interface where it arrived, and from there travels toward the initiator device.

Color Mode Considerations

Part of the bandwidth profile, the colour-aware statement helps enforce the required traffic parameters. The software processes ingress service frames according to their conformance (or non-conformance) to CIR and EIR. The software assigns a higher discard precedence to frames that conform to the EIR (known as yellow colored frames) than to frames that conform to CIR (known as green colored frames). You should expect yellow frames to be dropped first when the frames encounter congestion at the service layer. The software drops frames that do not conform to either CIR or EIR (known as red colored frames) at the interface, also known as traffic policing. Figure 3 shows CIR, EIR, and the mapping of colors to these rates.

Figure 3: Color Mappings to Information Rates

A few limitations and caveats for color mode:

Color‑aware validation requires a correct mapping of CIR and EIR to CoS and DSCP values. An incorrect mapping can invalidate per‑color results.
The maximum number of simultaneous tests that can run in color-blind mode is 16 tests. Color-blind mode is the default. You do not need to configure the colour-aware statement to get color-blind mode.
The maximum number of simultaneous tests that can run with the colour-aware statement configured is 8 tests.

VLAN Considerations, Limitations, and Caveats

For VLANs, we support only IEEE 802.1q encapsulation and untagged interfaces. For untagged interfaces, we support only color-blind mode. Therefore, do not configure the colour-aware statement.
In an end-to-end VLAN-symmetric network, VLAN and QoS parameters should not change, according to the ITU‑T Y.1564 standard.
For Y.1564 UNI egress initiators and the RFC 2544 egress initiators in the same VLAN using local bridging on all ports, ensure the same rewrite operations are configured for both initiators.
For virtual private LAN service (VPLS) and rewriting VLAN tags, you need to be aware of some additional restrictions. See Stacking and Rewriting Gigabit Ethernet VLAN Tags Overview.
Y.1564 terminators use the outer VLAN tag for packet filtering. Therefore, ensure VLAN symmetry. Ensure the reflected packet has the same outer VLAN tag and the same number of VLAN tags as configured for test packets generated from the initiator.

Supported Rewrite Type by VLAN Function

The Y.1564 feature supports certain rewrite types for ingress test traffic generated at the initiator:

Table 1: Supported Rewrite Types By VLAN Features for Y.1564 Ingress Test Traffic Generation
Rewrite Types	Local Bridge	VPLS	L2 CKT	L2VPN
pop	Yes	No	No	No
push	Yes	No	No	No
swap	Yes	Yes (On the reflector-side UNI, you should take care to swap with the same outer VLAN ID as the Y.1564 initiator-side UNI.)	Yes (On the reflector-side UNI, you should take care to swap with the same outer VLAN ID as the Y.1564 initiator-side UNI.)	Yes (On the reflector-side UNI, you should take care to swap with the same outer VLAN ID as the Y.1564 initiator-side UNI.)
Push-push	Yes	No	No	No
Swap-push	Yes	No	No	No
Swap-swap	Yes	Yes (On the reflector-side UNI, you should take care to swap with the same outer VLAN ID as the Y.1564 initiator-side UNI.)	Yes (On the reflector-side UNI, you should take care to swap with the same outer VLAN ID as the Y.1564 initiator-side UNI.)	Yes (On the reflector-side UNI, you should take care to swap with the same outer VLAN ID as the Y.1564 initiator-side UNI.)
Pop-pop	Yes	No	No	No
Pop-swap	Yes	Yes (supported for inner VLAN tag swap)	Yes (supported for inner VLAN tag swap)	Yes (supported for inner VLAN tag swap)

Configure Y.1564 Ethernet Service Activation Test

Use ITU‑T Y.1564 tests to validate SLA parameters in operational networks. A test consists of general settings and one or more services. Each service defines its bandwidth profile steps, color behavior, frame pattern, flow identifiers, and SAC. After you run the test, review the PTR for results.

Note: You cannot run Y.1564 and RFC 2544 tests simultaneously on the same interface. Only one Y.1564 test can run on an interface.

In this sample configuration, you configure round-trip testing. One device (host1) is the initiator and terminator; another device is the reflector (host2).

See Feature Explorer: ITU-T Y.1564 Ethernet Service Activation Test Methodology for supported platforms and releases.

Define the test’s general settings.

Specify:

Measurement mode—initiate and terminate.
Duration—between 1 minute and 24 hours.
Direction—ingress or egress.
Interface—entry point for packet generation.

Add a service to the test.

For each service under test, define:

Bandwidth profile steps—CIR, EIR, and traffic policing, including step durations.
Flow identifiers—source/destination MAC address
Frame pattern—fixed sizes or an Ethernet mix as needed.

Configure color‑aware mapping (if required).

Map CIR and EIR to CoS or DSCP values so per‑color results are reported correctly.

Define the SAC.

Define pass/fail thresholds for:

Frame loss ratio (FLR).
Frame transfer delay (FTD).

Commit the configuration on host1.
Save the test and service definitions.

Configure the reflector on the other device.

You are able to use the same reflector configuration as RFC 2544 benchmarking tests. You can use the same test name that you configured on host1, but we don't require that you do so.

Commit the configuration on host2.
Save the reflector definitions.
Start the RFC 2544 reflector on host2.
Start the test on the reflector.
Start the Y.1564 test on host1.
Run the test with the configured services and durations.
You do not need to explicitly stop the Y.1564 test because the test stops on its own when the test completes its measurements. If you stop the test after test completion, you see an error message similar to Error stopping test, no active sessions found.
Stop the RFC 2544 reflector on host2 after the Y.1564 test completes.
Issuing a stop command for the reflector during a running Y.1564 test leads to incorrect results. Use the show services monitoring y1564 command on host1 to check if the test is complete, then stop the reflector on host2.

Verify the PTR.

You can see this report by issuing the show services monitoring y1564 command. For example, to see the results for test1:

Review per‑service results for:

CIR and EIR
FTD
FL and FLR

Note: Confirm that the measured values meet the SAC you configured.

(Optional) Adjust test or service parameters.

If any service fails SAC thresholds, tune bandwidth profile steps, color mapping, frame patterns, or flow identifiers, then re‑run the test.

ON THIS PAGE