Y.1564 Ethernet service activation test
A Y.1564 test is a standardized Ethernet service activation methodology that
-
validates Service Level Agreements (SLAs) by measuring key performance metrics such as delay, jitter, loss, and throughput
-
provides a standard procedure for service turn-up, installation, and troubleshooting of Ethernet-based services, and
-
ensures consistent service quality and network performance in both User Network Interface (UNI) and Network-to-Network Interface (NNI) deployments.
|
Feature Name |
Release Information |
Feature Description |
|---|---|---|
|
Y.1564 Ethernet service activation test |
Release 26.1.1 |
Introduced in this release on: Fixed Systems (8200 [ASIC: P100], 8700 [ASIC: P100, K100], 8010 [ASIC: A100]); Centralized Systems (8400 [ASIC: K100]) Use the Y.1564 Ethernet Service Activation Test (SAT) to check SLA settings. Ensure all services meet SLA objectives at their maximum committed rate under maximum load. Conduct medium-term and long-term soak tests under stress. Use this procedure to turn up service, install, and troubleshoot Ethernet-based services. You can use this test to collect Key Performance Indicator (KPI) metrics, including Frame Transfer Delay (latency or Round Trip Time (RTT)) and Frame Loss Ratio (packet loss). Use the test to measure the non-drop rate and the maximum rate under stress conditions. |
SLA assurance for provider Ethernet networks using Y.1564
The ITU-T created Y.1564 Ethernet service activation tests to provide a common method for assessing Ethernet-based services for carriers and service providers. As Ethernet usage increases across provider networks, you can use standardized testing to ensure that your services meet SLAs even under stress and at full committed rates.
Key performance indicators (KPIs) for Y.1564
Y.1564 tests collect these KPIs to verify that configured SLAs are met:
-
Frame Transfer Delay (FTD) or latency: measures RTT taken by a test frame through the network.
-
Frame Loss Ratio (FLR): measures the number of lost test packets relative to packets sent, indicating reliability.
 Note |
Jitter is not directly measured in Cisco Y.1564 implementations. |
Main objectives of Y.1564 tests
-
To serve as a network SLA validation tool by confirming service performance within a controlled test time.
-
To ensure all services meet SLA objectives at maximum committed rate.
-
To provide medium- and long-term testing to confirm service quality under network load and stress.
The primary use case of SADT focuses on the non-drop rate (the rate where packet loss does not occur) and the maximum rate under stress conditions. Packet count has not traditionally been considered a factor.
Supported encapsulation modes for Y.1564 SADT
The Y.1564 Service Activation or Deactivation Test (SAT or SADT) feature supports different encapsulation modes to establish a baseline for Ethernet service behavior during a service activation test.
-
dot1q
-
dot1q + second dot1q
-
dot1ad
-
dot1ad + second dot1q
-
priority tagged
-
untagged
-
default
In two-way statistics collection mode, you send test traffic, and the remote node loops it back. You can then measure and collect statistics locally.
To learn more about default encapsulation, see the Virtual LANs in Layer 2 VPNs Chapter in the L2VPN Configuration Guide for Cisco 8000 Series Routers.
Restrictions for Y.1564 service activation test
-
Color aware mode is not supported.
If you classify the VLAN ID (VID), DEI, and CoS fields in the Ethernet frame header during SAT egress Ethernet Access Control Lists (ACLs), the ACL does not drop packets based on VLAN and class of service matches.
-
Layer 2 ACL and SAT interoperability not supported.
You cannot run SAT tests on interfaces with Layer 2 access control lists. You cannot configure Layer 2 access control lists on interfaces where SAT tests have already run.
-
SAT ACL sessions will fail if a Route Processor (RP) failover occurs.
SAT sessions do not persist across switchover (RP failover). You must restart the sessions after switchover.
-
SAT is not supported when the destination MAC address is a multicast address.
-
SAT does not support interfaces using VLAN rewrite.
-
Timer profiles and interoperability with BFD (Bidirectional Forwarding Detection) and CFM (Connectivity Fault Management)
The timer profile resource has these characteristics:
-
The SAT framework uses timer profiles. Each profile sets the interval or packets-per-second (pps) rate for packet generation. Eight timer profiles are available. The timer profile used depends on the packet-generation rate set for each session.
-
When SAT sessions are configured with different packet rates, each session requires a dedicated timer profile to maintain its unique pps rate. In this scenario, Four SAT sessions will consume four separate timer profiles.
-
If all SAT sessions operate at the same packet rate, they can share a single timer profile, thereby optimizing resource usage. Up to four SAT sessions can run concurrently using a single timer profile.
-
Resource usage and sharing
The timer profile resource is shared across multiple features, BFD or CFM. Careful planning is required to avoid contention, and ensure that SAT sessions do not impact or are not impacted by BFD or CFM operations.
-
-
The Layer 2 interface used for the SAT test must be configured under Layer 2 services before running SAT.
-
When you run SAT or Ethernet mix (EMIX) tests, the largest packet size allowed is 4096 bytes.
-
On K100-based Silicon One ASICs, 64-byte and 128-byte packets may experience up to one percent frame loss.
Usage guidelines for SAT and SADT testing
-
Use default encapsulation only without a Class of Service (CoS) value. CoS is not supported with default encapsulation.
-
Initiate only one session at a time with default encapsulation. The SAT engine uses only the CoS value to differentiate sessions. Default encapsulation packets do not include VLAN priority.
-
If your device has both untagged and default subinterfaces, run SAT sessions using the untagged subinterface. Packets sent over default encapsulation are processed by the untagged subinterface and the session will not function.
-
If both tagged and default subinterfaces exist, initiate the session over the tagged interface before starting the default session. This ensures both sessions function correctly.
-
Start the session on the tagged interface before beginning the default session. This prevents frame loss for tagged packets, which can happen if they are matched by the default PMF entry due to a missing VLAN priority.
Feedback