
Source: ITU-T
ITU-T Y.1564, also sometimes called (by mistake) “EtherSAM” - which refers to the draft of Y.1564 named Y.156sam, but while these names are in some cases used interchangeably there are some important differences between them. In this article we will refer to the rectified Y.1564.
Y.1564 is a QoS and network performance ITU-T Ethernet-based service test methodology. This out-of-service testing procedures test service turn-up, installation and troubleshooting of Ethernet-based services with the goal of assuring and verifying committed service level agreement (SLA) performances.
What makes this standard unique is that it allows for complete validation of Ethernet SLA in one test.
ITU-T Y.1564’s focus is threefold:
- First, the methodology serves as a validation tool, ensuring that the network complies with the SLA by ensuring that a service meets its key performance indicators (KPI) at different rates, within the committed range.
- Second, the methodology ensures that all services carried by the network meet their KPI objectives at their maximum committed rate, validating that under maximum load the network devices and paths are able to service all the traffic as designed.
- Third, service testing can be performed for a medium to long test period, confirming that network elements can properly carry all services while under a significant load extended over a significant period of time (sometime referred to as a soaking test)
Prior to Y.1564 the most widely used testing tool to assess performance of Ethernet-based services was IETF RFC 2544 which was created to evaluate the performance characteristics of network devices in a lab. But since it includes throughput, burstability, frame loss and latency with the lack of other standards it became commonly used in real networks and is being used in Ethernet-networks globally. It does not however include all required measurements such as packet jitter, QoS measurement and multiple concurrent service levels.
Contrary to other methodologies, Y.1564 supports current service providers offering which typically consist of multi-services. Y.1564 allows them to simultaneously test all services and measure if they qualify to the committed SLA attributes. On top of that it also validate the different QoS mechanisms provisioned in the network to prioritize the different service types – allowing service providers faster deployment (as the need for repeated tests is eliminated) and easier service and network troubleshooting.
Y.1564 allows for very high flexibility in simulating testing scenarios to be very close to the real active network traffic. It defines test streams (or “flows”) with service attributes aligned the Metro Ethernet Forum (MEF) 10.2 definitions. These Test Flows can be classified using various mechanisms such as 802.1q VLAN, 802.1ad, DSCP and class of service (CoS) profiles.
These services are defined at the UNI level with different frame and bandwidth profile such as the service’s maximum transmission unit (MTU) or frame size, committed information rate (CIR), and excess information rate (EIR).With up 5 different frame sizes in single test.
RFC2544 vs. Y.1564:
While existing methodologies like RFC 2544 work in the link level – measuring its maximum performance Y.1564 uses a different method where KPIs (such are Bandwidth CIR/EIR/DISCARDED traffic, Frame Loss, Frame Delay and Frame Delay Variation) are measured and compared to expected values for each service – ensuring it is within its committed range or the threshold defined for guaranteed traffic such as CIR (committed information Rate).
Y.1564 (EtherSAM) | RFC 2544 | |
Throughput | Tests performance at the CIR and ensures that the KPI are met constantly during the test. Excess and discard are not ignored and measured as well, ensuring policing and shaping mechanisms were properly configured in the network. | RFC 2544 only focuses on the maximum capabilities of a link with no separation of the committed and excess traffic, thus testing at the EIR level which is not guaranteed by the committed SLA (or more accurately the CIR). |
Frame Delay | Provides the peak latency and average latency measures during the test on all generated frames. Thus assuring that deviation out of the committed range or defined are identified, resulting in the actual latency of the service. | RFC2544 tests one frame in every test time, which doesn’t take into consideration any variation or peak that can occur over a longer test period. |
Frame Loss | Frame loss is measure is done during throughput test allowing for fast identification for any frame lost and reducing the service test time. | Frame loss is measured during rate distribution throughput test, in which frames are generated at specific intervals of transmission rates. However frame loss distribution doesn’t align with committed and excess rate profiles leaving important KPI out. |
Frame Delay Variation | Frame delay variation is tested during testing with traffic generated up to the CIR ,ensuring proper traffic prioritization and forwarding. | Not being tested by RFC2544. Requires additional test. |