Convergence by any other name would smell as sweet

It's clear that the network core will be multiprotocol label switching. But what will carriers put on the edge?

Convergence is a dirty word in some circles and definitely overused throughout the industry. But there is substance to the concept of data network convergence—and soon service providers will spend substantial dollars to enable it. I don’t want to confuse the subject: voice/data convergence or voice over IP is very much a part future of networking, but that effort will remain distinct from the data convergence for a few years.

For years, carriers have used a version of convergence using ATM to transport IP. But there is a new type of convergence, flipping the paradigm: using MPLS-enabled IP networks as the underlying transport for native IP and many legacy and emerging layer-2 data services including ATM, Ethernet and frame relay.

Vendors have done an admirable job proselytizing the MPLS convergence religion. As detailed in our forthcoming study, Service Provider Plans for IP, MPLS and ATM Networks, North America and Europe 2003, many of the carrier respondents are moving in that direction aggressively. The main reasons for this convergence is the promise of opex and capex savings—by eliminating network duplication and allowing the consolidation of edge boxes—while preserving and broadening the variety of access methods. And, as always with IP/MPLS, it promises new revenue and service opportunities.

ONLINE EXCLUSIVES WaveSmith jumps on MPLS wagon By Vince Vittore Mar 31, 2003, TelephonyOnline.com Netifice to introduce private network services over MPLS By Kevin Fitchard Oct 14, 2003, TelephonyOnline.com NTT, Motorola demonstrate new MPLS By Vince Vittore Oct 27, 2003, TelephonyOnline.com ON THE WEB MPLS Resource Center The MPLS and Frame Relay Alliance

Data network convergence, multiservice MPLS networks, integrated backbones and AT&T’s Concept of One: All of these terms feature a common goal and MPLS in the core. Yet each uses different terminology. Vendors and service providers use different language to describe their ideal solutions as well: MPLS convergence switch, multiservice switch-router, multiservice edge and converged packet switch. This leads to market confusion and muddies the clear goal of a service-agnostic MPLS core.

Superficially, the various convergence approaches look similar, but there are important differences in the details. The three main approaches for data network convergence are: ships in the night (SIN), MPLS network interworking and MPLS service interworking. The core is not in question—that will be MPLS. The battle is over what approach will be used on the edge.

Ships in the Night (SIN)
The hybrid model of the "ships-in-the-night" core uses ATM and MPLS control planes concurrently. It is the ability to offer ATM and MPLS over the same platform and even the same physical links at the same time. However, the ATM and MPLS control planes are isolated and do not interact; yet resources—switch fabric and I/O ports—are shared. This is a step away from the overlay model of separate equipment for separate networks, but the networks themselves are not integrated and are each unaware of the other (hence this model’s name: two ships passing each other in the night, blind to the act).

There are two forms of SIN, one of which the Internet Engineering Task Force (IETF) defines as ATM and MPLS control planes over ATM cells. There is another non-IETF defined version, which is not limited to an ATM port and is referred to by some as an integrated switch router—another muddy term for the masses.

Truly, only multiservice (for example, ATM/frame relay) switches support this method, as the platform must support native ATM switching and signaling, which are not present on any routers.

MPLS Network Interworking
This approach makes use of MPLS LSPs to tunnel layer-2 services across an MPLS core. The Layer 2 services on each end of the MPLS core must be the same (for example, ATM to MPLS to ATM), and the native edge services are emulated across the core. In essence, the convergence platform receives the native Layer 2 traffic, terminates it and encapsulates it using Martini-signaling—as defined in the IETF’s Pseudo Wire Emulation Edge to Edge (PWE3) draft—and switches it to an appropriate LSP (label-switched path) for transport over the MPLS backbone.

Multiservice switches and routers can support this method, with some real differences between vendors on how they treat the native Layer 2 signaling and quality of service as PWE3 does not address all aspects interworking. A key point of contention is whether the end-to-end provisioning of legacy services can be preserved. In the very least, the convergence platform must act as a label switch router (LSR). 

In addition, if LER (label edge routing) is supported, the convergence platform can take in native or “raw, unlabeled” IP traffic and forward it to the appropriate LSR. This allows for ATM, frame relay and IP VPN services to traverse a common MPLS core all from one edge device. However, if a multiservice switch is used for convergence, in most cases service providers will need an edge router in front of a multiservice switch to handle that raw IP traffic

In this approach, the control planes do not interwork, so there is no signaling between disparate endpoints (for example, one on IP and one on frame relay). That is the work of the next model.

MPLS Service Interworking
The third method also uses MPLS encapsulation based on PWE3. This method also emulates Layer 2 services over a packet network. The difference is that the control planes actually interact. There are no firm standards on this signaling interworking at this time, but it is in the works and many vendors are using some pre-standard implementations.

This approach allows for any service to interwork with any other service (for example, Ethernet with MPLS or with ATM). The protocols are actually translated from one to another—not one tunneled across another (which is network interworking).

Both multiservice switches and routers can support this method, but multiservice switch vendors have a leg up given their understanding of ATM and frame relay signaling.

This is an oversimplified three-part framework with many specific vendor differences. Overall, vendors are offering solutions for data network convergence from three angles: traditional frame relay/ATM switch with IP/MPLS enhancements, traditional router with ATM/MPLS enhancements or a new ATM/MPLS switch. Yet, in my view, there is limited consistency among the vendor offerings other than MPLS support and a mixture of ATM, frame relay and POS/Ethernet interfaces.

By no means are those the only choices carriers will need to make. There are other elements that are still unclear. One uncertainty is whether the approach used will be switch-based or router-based. Another is the question of core vs. edge convergence.  Core convergence maintains the legacy multiservice switches at the edge, but replaces the core with an MPLS network. Edge convergence starts moving customers off of multiservice switches onto newly deployed LERs.

And, as for that mixture of words to describe this phenomenon, at this time I don’t have a better solution than attaching modifiers in front of the word convergence and then explaining the nuances. In 12 months’ time, this language difference will be a moot point as the standards bodies and industry consortiums hammer out the differences and solidify approaches. Whatever term emerges, this convergence centered on MPLS is definitely on carriers’ minds—and vendors are pursuing the right end result.

---

Kevin Mitchell is Directing Analyst, Service Provider Networks and Next Gen Voice for Infonetics Research. He can be reached at kevin@infonetics.com.

Visit Infonetics online.