![]() |
|
| |||
| Bridging ATM to IP by George Shenoda TelephonyOnline.com, May 15 2002 The migration may be long, but multiservice switches can help carriers ease the transition | |||
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:
Even carriers that have
implemented MPLS maintain that ATM provides four attributes, especially on
a Sonet infrastructure, that are not possible today with MPLS:
In addition, two other
factors will further delay the adoption of MPLS:
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:
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. | |||
© 2002, Primedia Business Magazines and Media, a PRIMEDIA company. All rights reserved. This article is protected by United States copyright and other intellectual property laws and may not be reproduced, rewritten, distributed, redisseminated, transmitted, displayed, published or broadcast, directly or indirectly, in any medium without the prior written permission of PRIMEDIA Business Corp. |