Problem solve Get help with specific problems with your technologies, process and projects.

Using Ethernet as carrier backbone transport

Carrier Ethernet is making progress as a backbone transport technology, but there are challenges that must be addressed. The main issues, including maintaining scalability in large Ethernet networks, providing QoS to applications, and improving resiliency are discussed in this tip.

The key issues in Ethernet backbone deployment are maintaining scalability with very large Ethernet networks, providing QoS to applications that need it, and improving resiliency to ensure that failures in the core do not generate tens of thousands of customer complaints.

As network traffic has evolved from time-division multiplexed (TDM) to packet, providers have become more committed to backbone or "core" networks built on packet technology. In the 1990s, the growth of the Internet created a wave of interest in "convergence" on IP as the universal network technology. But IP networks have proved more costly than expected to operate, and in any event, packet protocols are multi-layered and IP is a Layer 3 protocol. Below IP, at the "data link layer" of the OSI model, are options like Packet over SONET (PoS) and Ethernet.

SONET technology has evolved since the days when OC-3 (155 Mbps) was considered fast, and now OC-768 (about 40 Gbps) is common. In fact, SONET standards have consistently kept ahead of Ethernet in terms of speed, and this has helped maintain SONET and PoS as preferred options. Recently, the combination of WDM/DWDM and faster Ethernet (10 Gbps Ethernet is now available, and 100 Gbps is being worked on by standards bodies) has raised interest in using Ethernet as the backbone in large packet networks.

Ethernet backbone applications can be broadly divided into interface and network applications. In the former, Ethernet is used simply as a point-to-point link layer protocol between devices, usually IP routers. In this application, the benefit of Ethernet lies in its lower cost relative to SONET. In network Ethernet applications, there is an actual Ethernet network built, over which IP and other higher-layer protocols travel.

Ethernet LAN technology is not suitable for network core deployment and, in fact, is unsuitable for carrier deployment in any application. The standards for LANs, particularly those relating to the size of Ethernet subnetworks and the bridging between subnets (spanning tree), are not scalable to carrier levels. The IEEE and Metro Ethernet Forum (MEF) have been working on a series of standards to create carrier-scalable Ethernet.

The key issues in Ethernet backbone deployment are maintaining scalability with very large Ethernet networks, providing QoS to applications that need it, and improving resiliency to ensure that failures in the core do not generate tens of thousands of customer complaints. How each of these is best accommodated depends on whether the provider intends to offer Ethernet services or simply use Ethernet as a path protocol under a service layer like IP.

Scalability in Ethernet backbone applications means better spanning tree. Rapid Spanning Tree Protocol (RSTP) offers better convergence in large Ethernet networks, and the Multiple Spanning Tree Protocol (MSTP) provides for VLAN-specific bridging needed for Ethernet services. Both may still create challenges, however, and current work on Provider Backbone Bridging with Traffic Engineering (PBB-TE), often called Provider Backbone Transport (PBT), eliminates spanning trees completely, allowing Ethernet to use a separate control plane such as GMPLS to create the bridging tables.

Where VLAN services are to be offered seamlessly from customer premises through the core network, most providers have determined that the "stacked VLAN" approach of IEEE 802.1ad will not support sufficient customers and flexible VLAN tag assignments to be commercially optimal. Instead, they opt for the 802.1ah approach (PBB). Some network architects believe that very large VLAN spaces are better served by using a hybrid of Ethernet in the metro network and an IP-based core.

Providing QoS at the network transport level, in today's thinking, is best accomplished through the PBB-TE/PBT mechanisms at the Ethernet level because PBT paths can be put into place and maintained statically. If Ethernet services are also to be offered, then it will be necessary to maintain the 802.1p class-of-services from VLANs and map them correctly to PBT trunks. Some vendors recommend that core VLAN interconnect be done via MPLS rather than through Ethernet, but PBT trunking should permit QoS control entirely within the Ethernet level. Still, when large scale and stringent QoS control are both requirements, an MPLS core may be a better approach.

Resiliency issues in Ethernet today are handled in the Metro Ethernet Forum's MEF 2 specification, and this is an excellent practices guide even for Ethernet backbone applications, particularly if Ethernet services are also offered directly from the backbone.

Another issue to be addressed in Ethernet backbone design is the relationship between Ethernet and other layers, and this is of particular interest in the area of managing availability and resiliency. If strong Ethernet path recovery exists, then higher-layer protocols like IP will not "see" failures, and recovery processes there can be less stringent. Similarly, if Ethernet is used over recoverable optical trunks, it is important that the Ethernet design accommodate the optical reconfiguration below (Reconfigurable Optical Add-Drop Multiplexers, or ROADMs) to ensure that there is no "hunting" of topology discovery created by multiple-layer fault recovery events.

All of these constraints must be considered within the context of a strong network and operations management plan. The MEF 2 specification addresses end-to-end Ethernet monitoring for OAM&P, and where PBT is used, the GMPLS or other control plane may be able to provide some detailed operations management and control links for a network management or OSS application. There is considerable standards work under way in Ethernet management, however, and it is advisable for backbone designers to check the state of the standards and the specific support offered for each by the vendors available before making a final vendor choice and finalizing their Ethernet backbone design.

About the author: Tom Nolle is president of CIMI Corporation, a strategic consulting firm specializing in telecommunications and data communications since 1982. He is a member of the IEEE, ACM and the IPsphere Forum, and publisher of Netwatcher, a journal in advanced telecommunications strategy issues. Tom is actively involved in LAN, MAN and WAN issues for both enterprises and service providers and also provides technical consultation to equipment vendors on standards, markets and emerging technologies.

This was last published in July 2007

Dig Deeper on Telecom Resources

Start the conversation

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

-ADS BY GOOGLE

SearchNetworking

SearchDataCenter

SearchCloudComputing

SearchCloudProvider

Close