PERFECTING THE ETHERNET HANDOFF

Standards groups are working to vault one of the final barriers to Ethernet ubiquity: dynamic, scalable inter-carrier Ethernet

Once confined to the local area network, Ethernet traffic has been seeping out in all directions, through campus and metro networks and even across the country. Perhaps the final barrier for this ever-expanding technology to overcome is the space between carrier networks. But to attain the sort of true ubiquity enjoyed by traditional telecom technologies, Ethernet must bridge the gap between one carrier's network and the next and do it in a highly scalable, automatic manner.

Though some carriers have been offering intercity metro Ethernet service over their own networks for some time now (e.g., AT&T, Time Warner Telecom), hardly any offer inter-carrier Ethernet service. Part of the reason for this is the lack of standards enabling the process. And wherever uniformity of service from one carrier to the next is key to offering a service (as it is in this case), standards are all the more paramount. Several standards bodies are forwarding multiple specifications to help establish common methods for inter-carrier handoffs of Ethernet (and other) traffic.

Last month, Broadwing announced what may be one of the first inter-carrier Ethernet services in a partnership with Hutchison Global Communications. The service, a 10 Mb/s Layer 2 virtual LAN (VLAN) that stretches across the Pacific Ocean to Hong Kong, changes hands at the GigE level in a carrier hotel at 1 Wilshire Blvd. in Los Angeles.

The Broadwing/Hutchison link is based on “Q-in-Q” technology, a method of segmenting Ethernet domains based on the IEEE's 802.1q standard and long applied to corporate LANs. That method required Broadwing and Hutchison to agree on the VLAN tags they would apply to their common customers' traffic. Of course, if they were to rack up a lot more customers, it would take a great deal of time to hash out the VLAN tags for each customer site — and each class of service to each customer site (right now, there's only one class), so the method doesn't scale well.

“The next step is to lean on the vendors and the standards bodies so we can have draft standards [for virtual private LAN service] analogous to what's being discussed on the IP side,” said Jamey Heinz, Broadwing's senior director of data product management.

On the IP side, RFC 2547, the Internet Engineering Task Force's (IETF) standard for IP VPNs, offers three options for inter-carrier VPN routing: A, B and C. Although option A is quite common in today's networks, option B allows for “autodiscovery,” the kind of automatic function that would allow carriers to greatly scale their inter-carrier links without the need for the manual configuration performed by Broadwing and Hutchison.

However, some critics have complained that option B (and C, for that matter) is too complex. (One service provider employee wrote in a November 2005 e-mail to draft authors, “[A, B, and C] are a poor set of options to choose from. I find each option to be some combination of difficult-to-manage and over-exposing.”)

“[Option B] is relatively new,” Heinz said. “Vendors haven't adopted it into their equipment yet. When I found out nobody really does it, I became less concerned with it.”

Lately, others have authored standards drafts that offer alternatives to A, B and C. One, authored in October 2005 by Tellabs employees Marko Kulmala and Ville Hallivuori, et al., includes an option “D” that combines aspects of A and B.

In parallel with these efforts, other standards bodies such as the IETF, the Metro Ethernet Forum and the MFA Alliance are working to bring similar capabilities to Layer 2 VLANs. The MEF's technical committee is working to finalize a specification for external network-to-network interfaces (ENNI) that would govern inter-carrier Ethernet. Based on the IEEE's “Ethernet first mile” standard, 802.1ah, the MEF ENNI method encapsulates each Ethernet frame with a MAC header for transport across neighboring networks. The MEF is likely to seek member approval for the ENNI spec in late spring, said Andy Malis, Tellabs chief technologist. He predicts that commercial gear based on the spec could arrive before the end of the year.

Following perhaps three to six months behind the MEF on this trail is the MFA Forum, which is working on a broader version of the MEF's ENNI spec, applicable to a range of MPLS-based services in addition to carrier Ethernet. This standard would govern the transport of both Ethernet and IP VPNs over MPLS, for example, as well as specifying other characteristics such as resiliency, security and quality of service. The group will likely solicit revisions to the standard at its April meeting and resolve all comments on it in June, after which it would be voted on by members.

Meanwhile, the IETF's ongoing work in the area of pseudowires — a method of encapsulating various kinds of next-generation and legacy traffic for transport across a common network — includes standards vital to inter-carrier Ethernet. Specifications already exist for the manual provisioning of inter-carrier pseudowires, but, like the Broadwing/Hutchison method, they're time-intensive and don't scale well. The “Dynamic Placement of Multi-Segment Pseudowires” draft standard — penned by the IETF's PWE3 working group — specifies methods for establishing pseudowires from one network (or “segment”) to another dynamically, with “autodiscovery” capabilities that automatically find VLANs without manual configuration. The PWE3's goal is to complete its multisegment pseudowire architecture requirements by June.

The work presents any number of engineering challenges, not the least of which is “specifying requirements for a technology that never existed before,” said Danny McPherson, chair of the PWE3 working group and senior director of business development for network security vendor Arbor Networks.

Beyond that, getting consensus on inter-carrier technology standards is tough because it requires network operators, each with their own distinct priorities and points of view, to agree on a common course of action.

“You want to be able to manipulate everything [in the network],” McPherson said. “My policies need to subscribe to the requirements of my network. I don't want my peer to be able to manipulate or ‘game’ me in any way.”

One of the biggest drags on the Dynamic Placement draft's development was a raging debate among contributors over which protocol would be used to set up and control MPLS networks: label distribution protocol (LDP) or resource reservation protocol for traffic engineering (RSVP-TE). LDP had been the basis of all the PWE3 working group's prior work. But Juniper Networks, which had a lot of experience deploying RSVP-TE, was among those pushing hard for its inclusion. In an e-mail exchange last June, influential standards author Luca Martini — who works for Juniper rival Cisco Systems — asked Juniper's Rahul Aggarwal, “Are you suggesting that we completely abandon all PWE3 work to date?” LDP ultimately won out.

“It was kept a technical argument, although there are extraneous motives there as well,” McPherson said. “Each vendor has a vested interest in different protocols, but operators really don't want two solutions.”

“LDP is more straightforward,” Malis said. “My personal feeling is that it's much more scalable [than RSVP-TE].”

Such standards will not only help bridge the gaps between carriers but even the gaps within them as well, as in the case of merged U.S. carriers with local and long-distance networks that are not yet integrated.

“They'll be discrete, autonomous networks,” McPherson said (at least initially). “That's one of the initial applications and key motivators of [multisegment pseudowires]. A prime example would be MCI and Verizon.”

Broadwing is betting that customer demand will light a fire under the standards process, fueled by early showcase models like its Hutchison partnership.

“There are lot of carriers abroad that have Ethernet and don't have VPLS — more than in the U.S.,” Broadwing's Heinz said. “They're knocking on the door. They want to come into the U.S. I'm hoping that helps spur some development.”

LEGEND

MEF Technical Committee Work Dashboard

SERVICE AREA	PROTOCOL AND TRANSPORT AREA	ARCHITECTURE AREA	MANAGEMENT AREA	TEST AND MEASUREMENT AREA
MEF 1-Ethernet Services Model (TS)	MEF 2-Protection Framework and Requirements (TS)	MEF 4-Metro Ethernet Network Architecture Framework Part 1 (TS)	MEF 7-EMS-NMS Information Model (TS)	MEF 9-Abstract Test Suite for Ethernet Services at the UNI (TP)
MEF 6-Ethernet Services Definitions (TS)	Transport Multiplexing Function (formerly EMF) (TS)	UNI Framework & requirements (TS)	Service OAM Requirements and Framework (TS)
MEF 5-Ethernet Traffic Management (TS)	QOS Framework (TS)	UNI Type 1 (IA)	Ethernet Service OAM (TS)
MEF 3-Circuit Emulation Service Requirements (TS)	Ethernet over Sonet (IA)	External NNI (E-NNI) (TS)	EMS Requirements (TS)
Services Phase 1 Unified Document	MPLS Protection (IA)	Eth-Layer Architecture Framework (TS)	Ethernet Performance Monitoring (TS)
PDH Emulation Services (IA)	Frame Relay Service Interworking Function (TS)	UNI Type II (Ethernet LMI) (TS)
MEF 8-CES over MENs (IA)		MPLS-based NI-NNI

TS — Technical specification
IA — Implementation agreement
TP — Test procedure

Approved draft
Sent to straw ballot
Sent to letter ballot
Approved

Source: MEF