SI
SI
discoversearch

We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor.  We ask that you disable ad blocking while on Silicon Investor in the best interests of our community.  If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.
Technology Stocks : FORE Inc.

 Public ReplyPrvt ReplyMark as Last ReadFilePrevious 10Next 10PreviousNext  
To: jach who wrote (10773)3/13/1999 12:34:00 PM
From: jach   of 12559
 
MPLS Compromise Cheers ATM, IP
Camps

By Joe McGarvey
March 8, 1999 8:27 AM ET

The warring camps in the Internet Protocol vs.
Asynchronous Transfer Mode debate may not agree
on much, but at least on one key technology point
they both say it's time to move on.

The Multiprotocol Label Switching (MPLS) standard
moved a little closer to consensus last month when
the Internet Engineering Task Force working group
that developed MPLS agreed to compromise on a
signaling system. Under the compromise, two
proposed signaling systems will be incorporated into
MPLS.

The compromise is drawing praise from developers
who favor an all-Internet Protocol (IP) approach to
networking as well as those who favor sending IP
packets over an Asynchronous Transfer Mode (ATM)
core. Both sides expect the agreement will push
product development plans forward.

"Progress on the standard gives us a base-level
definition so that we can begin doing some
interoperability trials," says Steve Vogelsang, senior
director of strategic marketing at Fore Systems, an
ATM switch maker.

MPLS, first proposed in the spring of 1997 to
establish a common approach to improving the
efficiency and intelligence of the routers and switches
that move information across the public network, was
stuck in gridlock over differing approaches to
exchanging information between routers. The two
protocols in contention were the existing Resource
Reservation Protocol (RSVP) and a new protocol,
Label Distribution Protocol, designed specifically for
MPLS.

Central Station

Now that the specification is nearing completion,
MPLS is expected to play a central role in the
emerging debate over the construction of
next-generation networks.

For those who advocate the construction of
high-speed networks that run IP directly over the
optical transport layer, MPLS represents a tool for
bringing some of the connection-oriented control
features of ATM - such as traffic engineering and
quality-of-service (QOS) management - to IP
networks.

Juniper Networks, which makes high-speed IP
routers, has been a major supporter of MPLS as a
traffic engineering tool. "The attractiveness of the
RSVP component of MPLS is that it is a mechanism
to reserve bandwidth and declare an explicit path
across the network," says Joe Furgerson, vice
president of marketing at Juniper.

By inserting specific routing information into the labels
that MPLS attaches to IP packets, service providers
will be able to override some of the constraints of
routing protocols now in use.

One of those protocols, open shortest path first,
dictates that a router pushes traffic over the most
direct path to the traffic's destination - even if that path
is congested. According to Furgerson, MPLS will
enable network engineers to dynamically alter traffic
routes - a process that's known as explicit routing - to
make the most productive use of network bandwidth.

"You may face the scenario that you are congested
on the shortest route but have capacity on a more
indirect route," Furgerson says. "Where you have
capacity and where traffic wants to go is never a
perfect match."

Juniper already uses an early version of MPLS in its
equipment, and at least two service providers, MCI
WorldCom and Frontier, are experimenting with the
technology's traffic engineering capabilities on a trial
basis.

In addition to traffic engineering, Juniper and others
plan to use MPLS to prioritize data flows, which will
enable service providers to offer customers different
classes of service. Just as routing instructions can be
inserted into MPLS labels, service providers will be
able to affix traffic-handling instructions to labels.

"The label can say 'Send this packet to this network
or with this delay characteristic' or 'Send the packet
with this type of bandwidth reservation,' " says Paul
Doolan, chief technology officer at Ennovate Networks
and one of the authors of the MPLS specification.

It Ain't Over . . .

While IP-only advocates hold MPLS as a path to
salvation from a dependency on ATM for QOS and
traffic engineering attributes, backers of the
IP-over-ATM strategy are not exactly preparing for last
rites.

"It works both ways," Fore's Vogelsang says. "We
now offer much tighter integration with IP, and this will
allow us to expand into the same area as Juniper and
other IP router makers."

One of the biggest knocks against running IP traffic
over an ATM core is the amount of overhead that is
required to convert IP packets to ATM cells and to
map the flow of traffic from a connectionless IP router
to a connection-oriented ATM switch that assigns
virtual circuits to traffic flows.

To make the relationship work, service providers must
mesh a separate routing layer with the ATM signaling
layer, Doolan says.

"You're using two fairly complex pieces of software to
achieve one thing," he says. "MPLS allows you to
bypass these two signaling plains."

The one caveat with MPLS, Doolan says, is that ATM
vendors will be required to add MPLS-specific
software to their switches to take advantage of the
technology. Vogelsang says Fore already is working
on such alterations for its ForeRunner ASX-4000 and
other high-end gear.

Although a crucial obstacle in the path of adoption of
MPLS has been cleared, members of the IETF's
MPLS working group declined to estimate when the
standard will be finalized. The IETF's next meeting is
scheduled for March 15 in Minneapolis.
Report TOU ViolationShare This Post
 Public ReplyPrvt ReplyMark as Last ReadFilePrevious 10Next 10PreviousNext