★ wanayoo — archive 1999 http://data.com/tutorials/atm_mux.htmlNouvelle recherche | Portail wanayoo
CMP's TechWeb Click Here to Vist CMPNET


Data Communications
Search Data Communications

 Browse By...
 Technology/Topic
 Vendor
 Issue

 Visitors Center

 FAQs
 Contact the Editors
 Registration
 Subscriptions

 Content
 TECH TUTORIALS
 ATM
 Carrier-Class Gear
 Internet/Intranets
 IP Tools/Issues
 Network Software
 Net Management/SLAs
 QOS
 Remote Access
 Routers/Switches
 Security
 Servers/Peripherals
 Services/Outsourcing
 Workgroup Networks

 NEW PUBLIC NETWORK

 LAB TEST CENTER

 GLOBAL NETWORKS

 PRODUCT LEADERS

 OPINIONS/COLUMN
 Viewpoint
 Lippis on Internetworking
 Sound Byte

 Marketing Services
 T99 Media Services
 Industry Front & Center
 Reader Service

 Custom Publishing
 Vendor Strategies
 Sponsorships

Click Here to Vist CMPNET

TechWeb Sites
 Byte.com
 CMPmetrics
 Data Communications
 File Mine
 InformationWeek
 InternetWeek
 Network Computing
 Planet IT
 TechShopper
 TechWeb News
 Tele.com
 WebTools
 Winmag.com

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 ]



Home Contact Editors Lab Tests Registration Tech Tutorials
Buyer's Guide Global Networks Opinion / Columns FAQs Subscriptions

CMPnet Click Here to Vist CMPNET