Bridging ATM to IP

May 15, 2002 12:00 PM, George Shenoda

The success of IP over the past few years in handling Internet traffic led many to believe that IP could potentially become the sole cost-effective architecture to resolve the complexities of interoperating packet and switched networks, and seamlessly deliver all types of services including voice, video, data, Internet and other applications over an IP converged network.

The recent downturn in the telecom market, however, has lifted the cloud of hype and led the industry to realize that due to the entrenched nature of incumbent service provider voice and data organizations, coupled with the large investments in legacy equipment, ATM, IP and TDM will coexist for the foreseeable future and play complementary roles.   

Carriers also realize that while it is important to protect legacy investments, the promise of IP will nevertheless allow them to further control operating costs, realize savings in network infrastructure capex and launch new revenue-generating services in the face of dwindling revenues especially in voice transport services.

IP, however, does not currently have the necessary capabilities to maintain quality of service for voice traffic in the presence of lower-priority traffic. In addition, IP services do not generate the same level of revenues as fast packet and are therefore currently not a driver for convergence.

Multiprotocol label switching (MPLS) promises to rectify several shortcomings of IP in converged networks, yet it is still not clear when full standardization with vendor interoperability will occur. In the meantime, ATM is solidly entrenched in service provider backbone networks today delivering services and revenues.

As a result, to protect legacy infrastructure investments while simultaneously preparing for future IP-based benefits, service providers will be best served to deploy switching equipment that can bridge current ATM and future IP/MPLS-based networks and provide a seamless network evolution plan. Omniservice switches give service providers the ability to augment their ATM-based networks today while providing IP/MPLS capabilities in the future.

The state of current networks

In the past few years, although some next-generation service providers like Level 3 opted for an all-IP network, ATM has nevertheless become the dominant architecture in wide area backbone networks mainly for its quality of service and traffic engineering capabilities. Operators have deployed ATM to improve core network performance or to interconnect their routers at Sonet speeds. Carriers offering DSL services have invested heavily in ATM backbones and, for the foreseeable future, ATM will remain as the transport network of choice for the local loop for DSL, especially for the ILECs.

Service providers providing real-time video services for the broadcast industry and data services for publishers have selected an ATM backbone as well. ATM's capabilities have also been used to establish managed-data service platforms for international carriers such as Infonet, WorldCom and Equant.

ATM provides reliability and proven quality of service for service level agreements and packet prioritization for real-time voice. In effect, in most instances the backbone network protocol for carrying packet-based voice traffic is ATM, even when the services offered to the customer is VoIP such as the case for carriers like Global Crossing and Williams Communications, which have implemented VoIP and are running the service over ATM backbones. 

In many cases, ATM can provide more efficient bandwidth usage for voice transport than TDM. In fact, some incumbent service providers like British Telecom have expanded their ATM backbones to offload Internet traffic from their TDM networks.

In addition, an important aspect of ATM that makes it a great protocol for converged voice and data networks is its multiple service classes and support for a range of traffic types and characteristics.

The future promise of IP/MPLS

Despite ATM's dominance, the prevalence of IP data services coupled with service provider requirements for higher capacity and more scalable networks, has placed MPLS at center-stage. MPLS is slated to bring the traffic engineering and reliability attributes of ATM to IP, provide cost and operational efficiencies for IP traffic and be an enabler for new IP-based services. MPLS promises to provide today's ATM signaling capabilities to IP converged networks in the future.

The need for bridging ATM to IP

The Yankee Group had predicted that 2001 would be the year that MPLS would begin to see wide deployment, effectively moving "ATM as we know it today" out of the network altogether.

This prediction has not materialized because MPLS development and standardization up to now has been unable to deliver on four crucial service provider requirements:

• Quality of service

• Vendor interoperability

• MPLS-to-ATM interworking

• Network resiliency to recover from fiber outages

Even carriers that have implemented MPLS maintain that ATM provides four attributes, especially on a Sonet infrastructure, that are not possible today with MPLS:

• Highly reliable transport

• Guaranteed performance

• Low latency

• Security

In addition, two other factors will further delay the adoption of MPLS:

• The phenomenal growth of 200% to %400 in ATM and frame relay services are generating significant revenue, and carriers will not cannibalize those for an unproven technology.

• The level of expertise with MPLS equipment and networks is anemic in both service provider and vendor organizations. Service providers know that they will have to spend valuable financial resources to have vendors design and manage their MPLS networks while knowing that the vendors' expertise and level of experience does not warrant the financial outlays. 

To reiterate, today the majority of service provider networks are ATM-centric, but with the best of intentions, they may eventually move to IP/MPLS when the technology had been proved. Because of all the above reasons, it is important for service providers to select and deploy equipment that can function as a bridge between current ATM and future IP/MPLS networks.

Network evolution strategies

We have refrained from using the phrase "network migration," since the term has connotations of a mass exodus (i.e., of equipment) or flight, as in the migration of birds, whereas a service provider network by its very long-standing nature cannot be migrated to a new technology but rather it has to undergo an evolution and be augmented and optimized through time with new state-of-the-art technology.

The evolution to IP/MPLS would be a four-step process:

1. Use ATM as the convergence network of choice for both voice and data services

2. Implement the Ships-In-the-Night protocol and run ATM and MPLS concurrently

3. Interconnect the ATM and MPLS networks

4. Complete the deployment of an all-IP/MPLS network. The last phase will not happen at least for the next five years. History shows that it takes an average of 10 years for a technology to sufficiently mature for ubiquitous deployment.

Step 1: ATM

Service providers with ATM backbones live by the mantra that the ultimate strategy in network evolution is maintaining their capital and human resource investments in ATM technology while slowly introducing IP/MPLS into segments of their networks. This strategy is especially important in today's telecom environment because most service providers are very frugal with existing capital spending budgets. 

As a result, economical carrier investments today will be in products that have numerous uses across multiple networks, as well as have the capability to take full advantage of ATM networks and also be able to integrate IP/MPLS capabilities when the standards are defined and well-established. Some omniservice switches provide these capabilities today.

In addition to traditional multiservice switching capabilities (ATM/IP switching, DSLAM aggregation, integrated packet DCS, as well as frame relay and IMA aggregation) the packet voice switching capabilities of these switches include the functionality of media gateways, softswitches and open interfaces to third-party application servers to give carriers a complete packet voice (VToA/VoIP) migration strategy.

Omniservice switches allow carriers to control a converged access pipe to the enterprise customer and offer new enhanced services such as VoIP or VPNs. The ATM switching fabric of omniservice switches also provide the necessary QoS for enterprise data. 

These switches use ATM switched virtual circuits, which provide for much higher bandwidth usage efficiency in the core network while PNNI provides for network resiliency and availability through rerouting around failed links. Omniservice switches also provide a viable migration path to hybrid MPLS/IP networks when carriers are ready and the technology is standardized and available.

The next step toward an ATM-based converged network is the packetization of voice traffic and using the packet tandem capabilities of the omniservice switch, which sport more than 20 gigabits of core capacity to handle both voice and data. 

In this phase, the TDM tandem network will be augmented with a packet backbone, and the packet tandem capabilities of an omniservice switch is a logical place to continue the growth after multiservice edge capabilities have been installed. A omniservice switch can interact with a traditional tandem switch in a variety of ways including acting as a simple trunking gateway or peering with a Class 4 switch.

A omniservice switch provides its own ATM switching capability directly over the existing transmission infrastructure, in addition to the media gateway functionality, thus saving the carrier from having to install an ATM network or expand an existing ATM network. This is especially crucial in light of the eventual evolution to IP/MPLS. 

When the omniservice switch is ready to augment and replace Class 5 switches with adequate features and robustness, service providers can evolve the IMTs between the Class 5 and the tandem switches from circuit-switched (TDM) to packet-switched (ATM/IP) technology, especially to take advantage of existing Class 5 switches before they reach adequate capital depreciation levels, while still using the packet tandem functionality.

Steps 2 and 3: ATM and MPLS

The transition of ATM/frame relay to pure MPLS will most likely happen in much the same way that customers evolved from X.25 to frame relay--gradually, in phases and over several years. By the time carriers converge both their voice and data on an ATM-based omniservice switch, MPLS may have made strides in standardization and vendor interoperability, and should be ready for the real world and carrier testing.

During this phase, both ATM and MPLS can control the network's resources in an operational mode called Ships-In-the-Night. Service providers will move their data and non real-time UBR traffic to MPLS label switched paths, but keep the constant bit rate (CBR) and variable bit rate (VBR) traffic (i.e., voice and video) on ATM connections. A change in an MPLS label switched path will have no impact on an ATM virtual circuit.

The omniservice switch will support running MPLS and ATM concurrently yet separately and will be able to connect to non-MPLS nodes. PNNI is still used on ATM switches to provide ATM services, and MPLS is used for IP services. At this point, the switch is operating as both an ATM-capable switch providing services such as circuit emulation and ATM UNI, as well as a label switched router providing, as an example, end-to-end IP VPNs. MPLS enables the VPNs through its ability to create virtual connections or tunnels across the IP networks.

Layer 2 services are the bread-and-butter of service providers today, and if MPLS is to succeed, it will need to provide for the uninterrupted provision of these services while service providers evolve their networks to IP/MPLS. Various IETF drafts (including Martini) are slated to address this crucial issue. 

Step 4: Voice Over MPLS

Although we do not expect this phase to happen before the next 5-8 years, during this stage, service providers can progress to moving the sensitive real-time traffic including VBR-rt and CBR over MPLS label switched paths, provided the technology proves economical.

In this instance the omniservice switch will be a "gateway" that contains the functionality of a label edge router. It can interface between the MPLS network and other MPLS, VoIP, PSTN or VoATM networks. It will also have the ability to interface with other access devices.

The evolution from an ATM-centric to an IP/MPLS-based network will be deliberate and slow and requires equipment that can take full advantage of ATM's capabilities especially toward the convergence of voice and data, as well as ultimately integrate the capabilities of IP/MPLS. Carriers can take advantage of the multiservice and packet tandem capabilities of omniservice switches to unify their networks and subsequently embark on the road toward IP/MPLS. The first step would be the adoption of the Ships-In-the-Night protocol where ATM and MPLS can run concurrently yet separately. The second step, which is not expected to happen before the next five years, would be to support voice services as well, over MPLS.

George Shenoda is the Founder and Chief Technical Officer of Oresis Communications. He can be reached at gshenoda@oresis.com.

Visit Oresis Communications online.