|
June 1997
By Robin D. Langdon, Larscom Inc.
ATM Monitor: Inverse Muxing
ATM Inverse Muxing
For Easier Access
|
|
Ask net managers to name ATM's biggest challenge and they'll likely point to the desktop, citing stiff competition from fast Ethernet and its gigabit kin. But ATM faces a problem on the WAN as well. Not at the core of public networks, of course, but at their
edges.
ATM (asynchronous transfer mode) access services are few and far
between. And when they do exist, they typically offer more bandwidth
than net managers need or are prohibitively priced--or both. Few
companies need or can afford T3 (45-Mbit/s) or OC3c (155-Mbit/s) pipes
to link branch offices. True, some carriers are beginning to provision
native ATM T1 (1.544 Mbit/s). That brings the price down, but the
bandwidth gulf between T1 and T3 is simply too big. Many companies
need something in between the two.
That's where ATM inverse multiplexing (sometimes known as
"imuxing") comes in. Unlike a conventional multiplexer, which
aggregates multiple low-speed links into one larger pipe, an inverse
mux takes traffic from a relatively high-bandwidth connection (say, a
campus ATM backbone running at 155 Mbit/s) and spreads it across
multiple lower-speed WAN circuits. Rather than paying for 45- or
155-Mbit/s WAN capacity that may be underutilized, net managers now
can deploy exactly as much WAN band
width as they need. And when
multiple circuits are inverse muxed, they appear to customer equipment
as one logical pipe.
The ATM Forum is currently in final ballot process on a spec for
inverse muxing ATM circuits on a cell-by-cell basis. Votes will be
collected and tallied at the end of this month. In addition, the forum
has already defined a method for converting ATM cells into bits, which
can then be transported via an inverse multiplexer over any WAN
circuit. There are pros and cons to both schemes; the key is in
understanding how each works.
Inverse Notation
|
 MESSAGE SERVER
Join the discussion about ATM Inverse Muxing
|
Inverse muxing is hardly a new concept. Net managers have used it
for years to
split a single data stream across multiple lines. This is
done in a round-robin fashion, so each data unit (bit or packet) is
shunted onto a different line. Further, the multiple WAN links appear
to the end devices as a single logical circuit. For example, several
T1s can be logically combined to form a single virtual data channel
that is the aggregate of all the bandwidth (minus a small amount for
overhead). In other words, net managers get the bandwidth of
fractional T3 using readily available, less expensive T1 services.
ATM is particularly well-suited to inverse muxing. It can link
individual sites with clear-channel broadband data pipes. It's
scalable. It seamlessly links LANs and WANs.
|
 Inverse Muxing, Cell by Cell
|
The ATM Forum's new inverse multiplexing for ATM (IMA) spec is
actually a new UN
I (user-to-network interface). It takes a stream of
ATM cells and, on a cell-by-cell basis, divides it across multiple WAN
links (see
Figure 1
). Here again, this is done in a round-robin
fashion, with individual cells recombined in their original order when
they reach their destination. To reduce WAN bandwidth consumption, IMA
removes idle and unassigned cells from the stream; these are
reinserted at the receiving end.
The IMA UNI rides on top of a T1 or E1 (1.544 or 2.048 Mbit/s) ATM
PHY (physical interface), performing inverse multiplexing using the
IMA control protocol (ICP). The PHY committee of the ATM Forum defines
how ATM cells are mapped onto physical layer media; UNIs and PHYs are
usually inseparable. In this case, IMA uses a cell-based control
protocol that aggregates the WAN links. That's a major departure from
the normal PHY definition, which usually describes only how cells are
delineated and managed for a given PHY.
IMA Believers
Many equipment vendors have already pledged support for IMA, and
the new spec is likely to be widely adopted in both carrier and
private networks. Within carrier networks, IMA can be used instead of
T1 ATM for point-to-point trunking between frame relay and ATM
switches, greatly increasing bandwidth without the need to upgrade to
T3 or OC3c. For corporate network managers, IMA's implicit promise of
interoperability means an end to single-vendor schemes for
inverse-muxing ATM.
But it will take time to implement IMA. Since it's a new UNI it
will migrate slowly onto the enterprise. It might first appear in ATM
switches and over time make its way to routers and adapter cards.
Early adopters will have to make a number of adjustments as new
hardware and software is rolled out. And interoperable N x T1/E1 ATM
services may take some time to appear: Different vendors designing
products to the same spec can choose slightly different
implementations, based on their interpretation of the spec. Thus, one
vendor'
s IMA gear may have trouble talking to another vendor's--at
first.
Bit by Bit
Net managers who decide that bleeding-edge implementations are just
too risky in terms of cost and reliability have another
alternative--bit-based inverse multiplexing. In this scheme, ATM cells
are inverse-multiplexed bit by bit instead of cell by cell. Like IMA,
this approach allows multiple T1s to be aggregated. The major benefit,
besides immediate availability, is that ATM traffic can ride over any
WAN circuit.
|
 Inverse Muxing, Bit by Bit
|
Bit-based inverse muxing is based on a specification approved by
the ATM Forum in 1995. It relies on cell-based TC (Transmission
Convergence) sublayer, also known as ATM Over HSSI (High-Speed Serial
Interface). Cell-based TC specifies a standard format for transmitting
cells
over any clear-channel bit-stream interface. At the physical
layer, V.35, HSSI, or any other type of physical interface that
accepts a bit stream can be used. The cell-based TC spec defines the
bit order and how the "start-of-cell" is determined. After that, cells
are simply placed bit-by-bit onto the transport mechanism (see
Figure
2
). The cell-based TC spec does not address issues like physical
interfaces, clocking, or modem control, but these are defined by other
standards.
ATM AnyWAN
Bit-based ATM inverse muxing means ATM traffic can be carried over
any WAN circuit, including fractional T3, fractional E3 (34 Mbit/s),
and T1/E1--even circuits already used to inverse multiplex other
services.
It's also possible to use an ATM T3 or OC3c UNI directly from an ATM switch, without having to make any changes to the switch itself.
That's important because bit-based ATM imuxing, unlike IMA, employs
existing UNIs. Remember, there are no guar
antees that all vendors will
support the new UNI. And even at the ATM switch, a new UNI means a new
interface, with the intended goal of converting from one rate to
another. It also requires buffering of cell traffic moving between old
and new UNIs.
Since bit-based imuxing doesn't need a new UNI, it's less expensive
to implement than IMA. In actuality, net managers don't even need to
use an ATM switch: With a bit-based ATM inverse multiplexer, a device
such as a router, high-speed workstation or server equipped with an
OC3c or T3 ATM adapter can connect directly into the inverse mux.
Thus, a readily available ATM interface such as a T3 or OC3c becomes
the ATM "DTE port" from which the data stream is transported across
the WAN via multiple T1 or E1 circuits.
For example, at a live demo at the recent Networld+Interop show in
Las Vegas, an MPEG 2 data stream from a Windows NT server equipped
with an ATM network adapter was first shunted to an ATM switch and
then to an inverse multiplexer. From th
ere it was sent across eight
T1s to another inverse mux, which connected directly into a PC client
equipped with an ATM adapter.
Backbone Bits
|
 ATM Traffic, Any WAN
|
So much for the mechanics of bit-based inverse muxing. To
understand the benefits it can deliver, it's helpful to examine some
network design examples. Consider a company looking to build an ATM
intranet that links multiple branch offices. With bit-based inverse
muxing, the ATM backbone can ride over multiplexed T1/E1 or fractional
T3/E3 circuits--without making any changes to the ATM switches being
linked (see
Figure 3
). And when it's time to upgrade ATM WAN circuits
in the future (perhaps to T3 or OC3c), the cutover won't require
changes to the UNI, thus protecting the company's original A
TM
investment.
Inverse muxing also is useful when ATM is required for some, but
not all, applications. Bit-based ATM inverse muxing can combine ATM
traffic over the same fractional T3/E3 links used for non-ATM traffic.
For example, a channelized T3 can carry inverse-muxed router traffic
and T1 tail circuits from a PBX, as well as specific multimedia apps
running over ATM. That means migrating to ATM needn't be an either/or
scenario; companies don't have to convert all WAN access connections
to ATM in order to support what may be a relatively small set of
applications that actually require the high-speed switched service. N
x T1/E1 ATM access can be added incrementally, making the migration to
ATM less expensive and less risky.
These benefits extend to carriers as well. If a carrier already
uses inverse muxing to deliver frame-based services like frame relay
or SMDS (Switched Multimegabit Data Service), bit-based ATM inverse
multiplexing could be furnished without having to deploy new
equipment
. The carrier doesn't have to change its service facilities
or retrain personnel and retool to support a new inverse mux
technology. The only difference would be that the carrier's inverse
muxes would have ATM interfaces to its customers' premises instead of
the customary HSSI or V.35 interfaces.
Using bit-based ATM inverse multiplexing doesn't preclude net
managers from moving to IMA someday. By the same token it doesn't
imply that they must do so. Bit-based and cell-based ATM inverse
multiplexing are virtually indistinguishable in terms of function and
performance. The logical upgrade path from either technology is to
full T3 or OC3c when applications demand that kind of bandwidth. One
benefit of bit-based ATM inverse multiplexing is that the technologies
involved are readily available and well understood. Whenever the
customer decides to migrate to a higher-speed ATM access device, there
is no need for the user or the carrier to restructure the network.
Today's network can also be tomorrow's.
Robin D. Langdon is a senior product manager for Larscom Inc. (Santa Clara, Calif.), a vendor of ATM multiplexers and other WAN access gear.
[
Home
]
[
Registration
|
Subscriptions
]
[
Contact Us
|
E-Mail
]
|
|
|
 |
 |
|