Establishing edge-to-edge Ethernet service-level verification

By Manu Kaycee, Telco Systems -- Tools are available today that enable a service provider to define the service-level capability across the network, provision the service, and monitor the service performance to determine if the agreed SLA is being met.
Oct. 8, 2007
8 min read
Figure 1. Test heads embedded within the CPE provide service-level verification end-to-end within the subscriber data path.

Tools are available today that enable a service provider to define the service-level capability across the network, provision the service, and monitor the service performance to determine if the agreed SLA is being met.

By Manu Kaycee
Telco Systems


Like the services available on voice networks, Ethernet services need to be measured to ensure that they meet high availability, reliability, and performance requirements for delivery of end-to-end voice, video, data. The ability to guarantee certain levels of quality of service depends on the provider's ability to measure and assess equipment capabilities at all points within the service infrastructure. And long accustomed to having remote access to service performance data from their circuit network management tools, service providers now require the same sophisticated access to management data for their new Ethernet services.

Edge-to-edge service-level verification

Service providers who own the network end-to-end may be able to guarantee service levels over networks they own. However, once the service enters someone else's network, such guarantees become more difficult to determine. To meet the terms of their service-level agreements, they must have accurate and consistent data on the reliability and throughput/delay and characteristics of the devices and network connections over which their services run. The goal of edge-to-edge service-level verification, therefore, is to be able to verify and maintain service-level agreements (SLAs) across multiple providers.

Edge-to-edge service-level verification means that the service provider can provide measurement of conditions in the network including:


  • delay, jitter, and bandwidth between network components to validate the SLA capability of the network prior to initiation of a service offering as well as ongoing verification after a service has been deployed
  • fault detection and isolation to identify the occurrence and location of a problem to ensure that truck rolls are dispatched to the right place for the right reason
  • performance monitoring to create a proactive response before the network experiences problems.
The ability to run standardized tests on multiple occasions at different times of day can provide valuable trending information that can be used for capacity planning, improved bandwidth management, and guaranteeing SLAs.

A major challenge for providers of Ethernet services lies in the fact that it has typically been left to individual vendors' proprietary testing methodologies, which were only able to measure how their own equipment performed. Such a practice rarely gives an accurate view of the service edge-to-edge, since there are few, if any, single-vendor networks out there today.

Transport-agnostic, protocol-independent testing has became a requirement with the increasing emergence of Ethernet services where there are multiple protocols running over many diverse transport methods. In today's Ethernet service network, you're just as likely to find SONET over MPLS over Ethernet in addition to other protocols and transport methods running over the same network. To achieve accurate end-to-end measurement of services in today's multi-vendor, multi-technology networks, standardized testing methodologies are critical.

IETF to the rescue -- RFC 2544

To address service performance analysis issues that emerged as a result of these heterogeneous networks, the industry turned to earlier work initiated by the Internet Engineering Task Force (IETF). RFC 2544 defines a number of tests that can be used to characterize performance characteristics of Layer 2 and Layer 3 network access devices and systems. In addition to defining tests for performance measurement and analysis, RFC 2544 also specifies formats for reporting the results of the service performance tests that are described. The test head function as defined in RFC 2544 provides carriers with a certain "comfort level" by defining well-known procedures familiar to carriers -- and methodologies that they know and trust. RFC 2544, as it applies to networking devices in an Ethernet services network, measures throughput, latency (and latency variation), and frame loss rate.

Most implementations of RFC 2544 testing still use external test heads. This can cause two major problems: (1) it's difficult to compute true edge-to-edge service performance by simply adding results between multiple single-hop tests, and (2) external test heads are intrusive. They must be installed at the customer site and they affect service, requiring that the customer be disconnected during testing. Since there are no single-vendor or single-hop services networks, the ability to manage services end-to-end is still somewhat compromised.

Moving beyond the limitations of today's intrusive, service-affecting testing implementations is the key to improving the measurement and analysis of service performance. And to deliver more and better services and guarantee end-to-end quality and performance of services, external test heads simply aren't up to the challenge.

Where we need to go

There are a number of basic steps that need to be taken next, beginning with the embedding of test-head functions into access devices at both edges of the network. RFC 2544-compliant embedded test functions could supply the clear and accurate view needed for effective Ethernet services that cross multiple networks and use multiple protocols and transport methods via equipment supplied by multiple vendors (Figure 1).

Embedded test heads ensure that service validation and assurance is conducted end-to-end and within the actual subscriber data path. These embedded test heads interwork with loopback entities to ensure that not only can assurance be performed over different Ethernet virtual connections (EVC), but also for specific customer traffic transported inside those EVCs. Once validated, services are monitored to ensure that they are performing to their agreements with respect to bandwidth, jitter, and frame loss, and that the network continues to provide the underlying performance and networking capabilities.

Accurately measuring services gives us the ability to analyze and manage them more efficiently -- and to say, with confidence, that these services are truly carrier-class. Tools like RFC 2544 make this possible; applying it in the Ethernet access network enables service providers to leverage the ubiquity of Ethernet to provide service scalability and end-to-end SLAs. The ability to measure, manage, and support multiple services and multiple service levels will enable providers to differentiate their offerings in a very competitive market.

Driving standards to measure performance

Edge-to-edge service level verification requires that the connectivity layer, the transport layer, and the services layer all work together.

Important steps have been initiated by standards organizations like the IEEE and IETF, as well as vendor consortia like the Metro Ethernet Forum (MEF), to create a methodology for measuring performance across multi-vendor networks and creating management interfaces for operations, administration, and maintenance (OAM) protocols, so that there is interoperability at the management level from different vendors (Figure 2).

As IEEE 802.1ag, ITU-T Y.1731, and the MEF Services OAM standards have evolved, the following are being increasingly deployed.

IEEE 802.1ag Connectivity Fault Management (CFM):Transport OAM defined in IEEE 802.3ah is complemented by connectivity OAM that is now standardized as IEEE 802.1ag. IEEE 802.1ag CFM describes a methodology to isolate the exact point of failure in multi-carrier networks, enabling end-to-end (rather than just link-to-link) management of connectivity and services. CFM introduced the concept of domains and supports autonomy for customers, providers, operators, etc. Multiple domains can be logically integrated, or each domain can run its own OAM.

For example, a provider can run its CFM OAM and isolate a problem to a single operator. The operator can then isolate the problem in its own network via its own CFM OAM. Such a capability is critical to keeping the cost of "virtual" truck rolls to a minimum, since it isolates which network provider in a multi-provider scenario owns the point of failure.

CFM defines messages and protocols across entire networks and is responsible for discovery and connectivity activities. In addition to finding maintenance end points and maintenance intermediate points, this standard also defines the link trace and loopback functions.

ITU-T Y.1731 Ethernet OAM for Fault and Performance Management: This standard deals with fault management in a manner similar to that defined in 802.1ag and Layer 2 performance management using a methodology similar to that described in RFC 2544. It also defines mechanisms for testing frame loss and delay.

Metro Ethernet Forum (MEF) Services OAM: This initiative defines end-to-end OAM for service assurance. (See also MEF 10.1, which describes service performance attributes, and MEF 9 and 14, which define testing methodologies for those Ethernet services.) This initiative also defines policies, but not the message packets or the test mechanisms to be used.

The ability to accurately analyze and manage services more efficiently enables providers to say, with confidence, that these services are truly carrier-class. This higher level of integration in the measurement and management of Ethernet services and procedural standardization at its core will broaden the appeal of Ethernet as a service-delivering technology and enhance the ability of Ethernet to deliver carrier-quality, multiservice access to the customer edge.

Manu Kayceeis vice president, product technology and strategy, at Telco Systems, A BATM Company.
Figure 2. A combination of methods is now available that, working together, can provide carriers with the service-level verification they require.
Sign up for our eNewsletters
Get the latest news and updates