An old proverb says “A fool and his money are soon parted”, but in most cases it’s not easy to get someone to part with their money, fool or no. Before opening one’s wallet to make any significant purchase, most want to be comfortable that they are making a good decision, especially today, when every dollar counts more than ever.

Whether buying a big-screen television or a telecommunications service, buyers want proof that they are being smart with their money. To determine this, shoppers look for validation, scouring the Internet, checking Facebook recommendations, and calling peers and friends.

When obtaining a telecommunications service, some of the key metrics are bandwidth, performance, and reliability. Before getting a new service, buyers want proof that it lives up to its claims in those metrics.

That’s where the recent ITU-T Y.1564 standard comes in. This standard provides some of that proof when it comes to Ethernet services. Before getting an Ethernet service, a prospective customer can know all about how it performs.

Why Perform Service Activation Testing?
Service activation testing is a benefit to all parties involved in delivering an end-to-end Ethernet service. Each party can validate that they’re getting, or delivering, something as promised.

The 3 parties involved in service delivery are operators, service providers, and customers. Customers buy end-to-end services from service providers, who in turn buy component services from operators. These relationships are shown in Figure 1.

Figure 1. The 3 parties involved in service delivery are operators, service providers, and customers. Customers buy end-to-end services from service providers, who in turn buy component services from operators.

As seen in Figure 1, one party obtains a service from another party, and it is in both parties’ interest to validate the service performs as expected. The primary function of Y.1546 is to validate the performance characteristics of a service before the service is accepted. Customers, service providers, and operators can all benefit from that validation.

Intrusive and Non-Intrusive Testing
Ethernet service testing can be performed using a number of tools, each with its own benefit. Some of these tests are non-intrusive, meaning that they run while the service is operational, and do not interfere with the traffic flowing within the service. Examples of non-intrusive service verification mechanisms include IEEE 802.1ag and ITU-T Y.1731. Other test methodologies can be intrusive, meaning that the test itself interferes with what is being tested.

Two non-intrusive service verifications are 802.1ag Connectivity Fault Management and Y.1731 Service OAM.

802.1ag Connectivity Fault Management verifies connectivity between specified measuring points in an Ethernet service. It continually monitors an Ethernet service and quickly detects if connectivity is lost between measuring points, providing the verifiable metric of service availability.

Y.1731 Service OAM extends the protocols of IEEE 802.1ag to monitor performance in addition to connectivity. Y.1731 determines not only that measuring points are reachable but what with loss, latency, and jitter they can be reached.

Both of these protocols operate by inserting relatively low-frequency OAM frames into the data stream that follow the same network path as data frames. They are considered non-intrusive because the service data frames are also being forwarded at the same time, and the low-frequency OAM frames have little impact on that.

ITU-T Y.1564, on the other hand, is an intrusive testing protocol. When Y.1564 is running, normal service frames are not being forwarded. Instead, Y.1564 inserts a high frequency of measurement frames into the network, and calculates performance metrics under a specified heavy load.

Other Alternatives
The Y.1564 standard is not the first or only intrusive load-testing methodology. The original and more famous load-testing standard is IETF RFC 2544. This RFC defines methods to test networks (or network elements) under specific load scenarios, and calculate metrics such as the maximum achievable bandwidth.

RFC 2544 has been used as a benchmarking methodology for years, but it has a few shortcomings for the Ethernet services scenario. First, it is targeted at the IP layer, not the Ethernet layer, and is thus not directly applicable to Layer 2 testing. Secondly, it performs a series of single, isolated tests, which is fine when benchmarking a network device in a lab, but falls short when testing a service in a network. For example, RFC 2544 doesn’t measure multiple metrics (i.e., latency and throughput) simultaneously. It also doesn’t measure latency under heavy load. And it can’t test multiple traffic classes simultaneously, etc.

With RFC 2544, each test of each metric is performed in isolation. And when looking at real services over real networks, that’s just not good enough.

Y.1564 for Ethernet Service Activation Testing
ITU-T Y.1564 defines more complex methodologies than RFC 2544 for measuring the performance of Ethernet services. The methods are intrusive and thus intended to happen before the service is activated or during a maintenance window.

Rather than just performing a simple test as in RFC 2544, Y.1564 allows you to run a sequence of multiple tests of variable duration and while collecting multiple statistics in parallel.

Y.1564 starts by first confirming that there is connectivity by running a short, low-bandwidth test. Once basic connectivity is validated, Y.1564 then runs through a sequence of tests, where each test generates a sequence of frames at a desired rate, and the reception of the frames is verified and measured for multiple performance parameters, including throughput, loss, latency, and jitter.

The simplest metrics to obtain are bidirectional metrics (measuring round-trip performance), though the standard allows for unidirectional measurements as well. To obtain bi-directional metrics, a loopback must be active somewhere in the network, and the frame generation and reception functions can then be collocated to measure round trip service behavior. (See Figure 2.)

Figure 2. To obtain bi-directional metrics, a loopback must be active somewhere in the network, and the frame generation and reception functions can then be collocated to measure round trip service behavior.

An example test sequence could use a set of frame sizes (64, 128, 256, 512, 1024, 1500, 2000), a set of frame rates (25% of line rate, 50%, 75%, 100%), and a fixed test interval (5 minutes). The entire activation test after connectivity verification would then be up to 28 sets of test results (4 network loads and 7 frame sizes), where each test result includes the generated and received load, the achieved throughput, the frame loss, the round-trip latency, and the round-trip jitter.

The Results and The Benefits
The result of the activation test should be a good benchmark view of how the service behaved across a variety of offered input conditions. Although there is no defined format for the results, Figure 3 provides an example of what such results could look like.

Figure 3. The result of the activation test should be a good benchmark view of how the service behaved across a variety of offered input conditions. Although there is no defined format for the results, this table provides an example of what such results could look like.

In this case the results verified that the service performed consistently across all of the different tests, with an average round-trip latency around 5.3 milliseconds and a standard deviation on the latency measurements of less than half a millisecond, with a relatively low frame loss ratio (at most 0.1% in any test). Whether these measurements are satisfactory is a matter for the local party to decide, but at least the performance data is measured and available under a variety of conditions. If the results are deemed satisfactory, the service can then be activated and the results archived for future comparison.

At any point in the future, the tests could be repeated and the results compared. This comparison would make it easy to identify any particular performance areas that have degraded or changed since the service was first validated and activated -- users would know for sure what’s different.

Y.1564 gives us the information needed to know what they’re getting before they get it. So, if you are purchasing an Ethernet service, demand a performance report from the prospective carrier before buying. And if you’re in the market of delivering Ethernet services, demand Y.1564 capabilities from networking equipment.

Dr. Matt Squire is CTO for Overture Networks. Matt has served on the board of directors at the MEF, held leadership positions in the ATM Forum and made numerous contributions to the IETF. For more information, visit www.overturenetworks.com.

What is your experience with this? Tell your fellow readers now!