Y.1564 - Ethernet Service Activation Test
With the deployment of Ethernet in service provider networks, ethernet services have evolved significantly. Not only is ethernet found at the User Network Interface (UNI) but can also be deployed anywhere in the network, creating a Network-to-Network Interface (NNI). With the capability to prioritize traffic, high availability, and its built-in resiliency, service providers are now using this technology to deliver advanced services. In the absence of any standardized test methodologies that can measure delay, jitter, loss, and throughput at a port, the ITU-T recommendation Y.1564 addresses the gap
Y.1564 - Ethernet Service Activation Test (or performance test methodology) is a testing procedure which tests service turn-up, installation, and troubleshooting of Ethernet-based services. This test methodology was created to have a standard way of measuring Ethernet-based services in the industry.
Cisco implementation of ITU-T Y.1564 has three key objectives:
-
To serve as a network SLA validation tool, ensuring that a service meets its guaranteed performance settings in a controlled test time.
-
To ensure that all services carried by the network meet their SLA objectives at their maximum committed rate, thus proving that under maximum load, network devices and paths can support all traffic as designed.
-
To perform medium-term and long-term service testing, confirming that network elements can properly carry all services while under stress during a soaking period.
The following Key Performance Indicators (KPI) metrics are collected to ensure that the configured SLAs are met for the service or stream.
-
Frame Transfer Delay (FTD) or latency—Measures the round-trip time (RTT) taken by a test frame to travel through a network device, or across the network and back to the test port.
-
Frame Loss Ratio (FLR)—Measures the number of packets lost from the total number of packets sent. Frame loss can be due to a number of issues such as network congestion or errors during transmissions.
Supported Modes
|
Feature Name |
Release Information |
Feature Description |
|---|---|---|
|
Default Encapsulation Mode of ITU-T Y.1564 |
Release 24.2.1 |
Introduced in this release on:NCS 5500 fixed port routers The default encapsulation mode helps to set a baseline to know how the Ethernet service behaves for default operations in Service Activation Test. |
The mode of operation that is supported for Y.1564 is the Two-way statistics collection mode. In the two-way mode, the sender generates the test traffic used to perform the test, which is then looped back by the remote node. The statistics are measured and collected locally on the sender
The following encapsulations are supported by Y.1564 SADT feature:
-
dot1q
-
dot1q + second dot1q
-
dot1ad
-
dot1ad + second dot1q
-
priority tagged
-
untagged
-
default
 Note |
Before Cisco IOS XR Software Release 24.2.1, default encapsulation is supported if there are no other subinterfaces configured with untagged encapsulation. Starting Cisco IOS XR Software Release 24.2.1, default encapsulation is supported. |
Restrictions for Default Encapsulation for ITU-T Y.1564 Service Activation Test
The following are the restrictions for default encapsulation mode for Y.1564 Service Activation Test:
-
Default encapsulation with cos value isn’t supported.
-
Multiple parallel sessions with default encapsulation aren’t supported. Default Encapsulation packets lack VLAN priority, and the SAT engine can only differentiate sessions based on the CoS value.
-
If there are subinterfaces for both encap untagged and default, then only the SAT sessions over untagged works. But SAT sessions over default encap don’t work. The packets are handled by an untagged sub interface.
-
If there are subinterface for both tagged encapsulation and default, then only the SAT sessions work over the default interface but not over the tagged interface. Both function only if the session over the tagged interface is initiated before the default session.
-
When the default interface session is initiated first, the absence of VLAN priority qualifier causes tagged packets to also trigger the default PMF entry, resulting in frame loss for tagged packets.
To know more about default encapsulation refer Configure Virtual LANs in Layer 2 VPNs Chapter in the L2VPN Configuration Guide for NCS 5500 Series Routers.
Usage Guideline and Limitations
-
Rewrite with POP option is supported with Color Blind mode with Outer-Cos value of 0.
-
Rewrite Push and Translate on Encapsulation Untagged is not supported.
-
Y.1564 doesn’t support L1 loopback.
-
Y.1564 over bundle with members from multiple NPU is not supported.
-
Y.1564 doesn’t support measuring and analyzing jitter.
-
When utilizing the SAT engine received bytes statistics feature, there can be potential inaccuracies in the following conditions:
-
During tests incorporating EMIX sequences that encounter packet drops.
-
When handling LMM packets originating from TGEN, Y.1731 protocols, or any unidentified sources.
-
-
SAT supports a scale of four parallel sessions per system. However, all four sessions can not operate as color aware sessions simultaneously due to limitations in Class of Service (CoS) combinations.
-
SAT over bundle interface functions by selecting one of its members for transmission. Therefore, at least one member must be in the 'UP' state to initiate an SAT session. For modular chasis, bundle member from the different LCs is not supported.
-
For optimal performance, it's recommended to use the Ethernet Data Plane Loopback functionality (EDPL) on the peer side for SAT. EDPL loops back and swaps the MAC addresses of Layer 2 packets generated. If the peer node doesn't support EDPL functionality, you can configure SAT to generate Layer 2 packets with the destination MAC address equal to the source MAC address. In such cases, the peer can perform an L1 loopback.
-
Packets generated by SAT with PRBS payload at certain packet sizes may have PRBS errors. When configuring GTF packet using bcm_sat_gtf_packet_config_set, this is verified. If the payload_type is bcmSatPayloadPRBS and packets generated at the configured packet_length have PRBS error, this API now returns BCM_E_PARAM to the caller. The user is informed about the PRBS error through the test abort reason.
-
On BCM8869X, packets have PRBS errors, if (packet_length + 63) / 64 is one of [4, 6, 10, 12, 13, 14] or > = 18.
-
On BCM8880X, packets have PRBS errors, if (packet_length + 63) / 64 equals to 6 or > = 33.
-
-
Use unique CoS values for CIR and EIR in parallel tests.
Platform GTF Rate
The following table includes the GTF rate for different platforms.
| Platform (PID) | GTF Rate |
| NCS540 | 19.2 Gbps |
| NCS560 | 19.2 Gbps |
| NCS540L | 19.2 Gbps |
| NCS4K | 23 Gbps |
| NCS5501 | 19.2 Gbps |
| NCS-5501-SE | 19.2 Gbps |
| NCS55A1-48Q6H | 23 Gbps |
| NCS55A2_MOD_S_SE | 23 Gbps |
| NCS-55A1-36H-SE-S | 23 Gbps |
| NCS-55A1-36H-S | 23 Gbps |
| NCS-55A1-24Q6H-S | 23 Gbps |
| NCS-55A1-24Q6H-SS | 23 Gbps |
| NCS-55A1-24H | 23 Gbps |
| NCS-5502-SE | 23 Gbps |
| N540X-6Z18G-SYS-A | 8 Gbps |
| N540X-4Z14G2Q-D | 8 Gbps |
| N540X-8Z16G-SYS-D | 8 Gbps |
| N540-6Z14S-SYS-D | 8 Gbps |
| NCS-57C1-48Q6-SYS | 300 or 400 Gbps |
| NCS-57C3-MODS-SYS | 400 Gbps |
| NCS-57B1-5DSE-SYS | 400 Gbps |
| N540-24Q8L2DD-SYS | 300 Gbps |
| NCS-57D2-18DD-SYS | 400 Gbps |
Feedback