| ★ wanayoo — archive 1999 http://www.data.com/tutorials/ima.html | Nouvelle recherche | Portail wanayoo |
|
|
|
|
|
|
But IMA is also useful for companies that don't want to set up a private net. Carriers can use the spec to offer affordable broadband services at rates from T1/E1 to T3/E3, which means customers can purchase ATM data services at the rates they require. What's more, IMA will enable carriers to offer native-speed LAN interconnect at 4, 10, or 16 Mbit/s without having to pull fiber right to the customer site--an expensive and time-consuming task. It also makes it possible to run high-speed ATM services over such media as microwave radio.
IMA-compliant products will vary according to scenario. Customers connecting to a public ATM service, for instance, will probably deploy ATM access devices rather than switches on their premises. IMA access devices will integrate legacy data, voice, and video tr affic, and any local ATM traffic for (cost-effective) transport over an ATM WAN. (It's also worth noting that IMA can accept multiple cell streams, combine them, and distribute them across the inverse-muxed link without losing any of the quality-of-service characteristics required by each stream.)
IMA can also be implemented within the WAN cloud, with a switch receiving multiple T1/E1 channels from an access device. The spec could also be used for linking ATM switches within a WAN--say, between a node in Paris and one in London.
So much for what IMA promises. Getting a handle on just how it's going to accomplish what its proponents say it will means taking a close look at the basics.
The ATM Forum's Physical Sub-Working Group is responsible for developing the spec. It's divided IMA into five functional components: inverse multiplexing, link management, source interface, cell function, and unit management. These components define IMA at a number of ATM protocol laye rs, including the physical layer, the ATM layer, and the management layers (see "Seeing Into the Stack"). The spec also contains a separate discussion on handling timing issues--essential if inverse multiplexing is to work over today's global networks.
As might be expected, the inverse multiplexing component is the most critical piece of IMA (and it's further subdivided into three parts). It performs the actual distribution of cells over the link group. Basically, it takes an incoming cell stream (or streams) and distributes the cells across the multiple T1/E1 links on a per-cell basis, using a cyclic round-robin approach. In other words, the first cell is sent on the first circuit, the second on the second, and so on (see Figure 2). So that the receiving end can reconstruct the cell stream, special control cells also are sent.
|
If the device at the receiving end is going to function properly, it requires a steady stream of cells. But sometimes individual traffic sources aren't transmitting traffic across the link--so the sending device has to introduce filler cells to keep the round-robin process at both ends in sync. If the sending and receiving ends are out of sync, the receiver won't be able to recreate the original stream correctly.
There's something else to keep in mind. Inverse multiplexing is transparent to the application and to the rest of the network; cell order and format is retained, and the required cell variation on eac h virtual circuit stays within the bounds negotiated when the call was first set up.
The three sub-components of the inverse multiplexing piece are the arbitration algorithm, the IMA frame, and the IMA Control Protocol (ICP) handler. They work together, with the arbitration algorithm handling the distribution of cells across the link in the round-robin scheme.
Consecutive cells on each link are grouped together to form an "IMA frame," with a frame size that's not specified. These cells weren't consecutive in the original stream of cells, since each was sent across a different link. The frames are used by the control protocol to manage data being transmitted.
Cells generated by the ICP are added to the IMA frame at designated locations. These cells furnish two kinds of control information: synchronization, which allows the sending and receiving devices to stay in sync, and configuration, which enables them to set up and maintain the links.
Sy nchronization information refers to everything that's needed to keep track of how cells have been distributed across circuits--from link identifiers to sequence numbers to stuffing indicators. Link identifiers act just as their name suggests, giving each link in the group a unique tag. Sequence numbers indicate the order of the cells, while stuffing indicators define cells that have been inserted to keep the sending and receiving devices in sync.
These stuff cells shouldn't be confused with the filler cells described above; they're sent to compensate for timing differences among the T1/E1 trunks within the same link group. Although all the links in the group run at the same speed, there's no guarantee that each has the same delay, which means that cells on some links may arrive faster than others. Hence the need for stuff cells, which the transmitting device inserts periodically on links that are operating at a faster rate.
At the receiving end, each link delivers data into its own buffer, whi ch needs to be deep enough to tolerate the maximum link delay variation. The receiving device uses buffer pointers to determine the maximum differential delay among the IMA link group. This information can be used to identify those links with excessive differential delay, which could then be removed from the group (see below).
The information also could be used to determine whether the IMA can service an ATM virtual connection with a particular set of characteristics. The IMA spec doesn't define a required buffer size, which depends on two factors: the type of data that's being transported, and the distance it has to travel.
ICP also is used to exchange IMA configuration information between the two end points. This data is used in the arbitration and handshaking processes constantly under way, conveying the status of the individual physical links comprising the group.
The same information is used by the second major piece of the IMA spec, the link manage ment functional component. It's responsible for establishing and tearing down connections for each trunk within the group. Whenever ICP cells are not received on a particular link (which can occur if there are transmission difficulties or if the link simply goes down), it can be deleted from the group automatically. A link can also be deleted automatically if its delay is too large. Failed links are automatically restored to the group once they've recovered from the failure.
For now, link management makes no provision for dialing up bandwidth on demand--but it's one of the sub-working group's goals. Eventually, there could be a mechanism for furnishing an additional circuit (most likely a primary-rate ISDN connection) when an application needs more bandwidth. The circuit could then be torn down when the bandwidth is no longer needed.
The source interface is the third functional component of the IMA spec. It furnishes the logical and physical connection to the attached devices. There are a coup le of options, depending on the type of IMA device. In the case of an IMA switch, the source interface is part of the switch's internal architecture. For IMA access devices, the source interface can be either DXI (data exchange interface) over HSSI (high-speed serial interface) or V.35.
The next component of the spec is the cell function, and how it operates depends on the form of the incoming data--that is, whether it's already in native ATM format or must first be converted from another format. If the incoming data consists of cells, the cell function does nothing.
If, however, the data is in Ethernet, token ring, or some other form, it has to be converted to cell format. In such cases, the cell function is responsible for segmentation and reassembly (SAR). For instance, a router with no ATM interface should be able to connect to an IMA access device, feed it LAN frames, and have those frames processed correctly by the IMA access multiplexer.
The fifth and final functional component of the spec is unit management. It handles management functions at the system level, furnishing management information regarding IMA system status, configuration, and alarms. It also defines an IMA management information base (MIB) that enables IMA devices to be managed by SNMP management platforms.
That's the basic description of IMA. What can the spec do?
One of its key capabilities is the support of operations, administrations, and maintenance (OAM) cells, which provide information about the quality of an ATM virtual circuit. It's one of the main reasons the forum chose to implement inverse multiplexing on a per-cell rather than a per-bit basis: With cell-based inverse multiplexing, the management and monitoring benefits of OAM functions are extended across the inversely multiplexed links. Thus an IMA access device and the ATM switching network can exchange monitoring information, and that makes for better network performance.
Why did the ATM Forum vote ag ainst bit-based inverse multiplexing? After all, a bit-based approach might have been easier to implement, and it generally results in lower delay variability. But the forum found that such an approach would have made it a lot more difficult to retain support for OAM.
The IMA spec requires the support of physical-layer OAM handling-- including the OAM functions laid out in the ATM Forum's DS-1/E1 specs and some of those included in ITU I.432. Among these functions are out-of-cell delineation (OCD) and loss-of-cell delineation (LCD) defects.
In addition, IMA generates OAM cells to reflect the status of the inverse multiplexing operation. Removal of a link is reported with an indication of the failure condition. (As noted, a link can be removed from the inverse multiplexing round-robin cycle because of missing ICP cells or excessive differential delay.)
One of the most critical challenges faced by IMA developers has been clocking and timing synchronization. It's a big issue, since the spec is likely to be used when links from different carriers (and perhaps different countries) are being deployed.
That's why developers have composed a detailed discussion of timing and added it to the IMA specification. It ends up making things easier for net managers: Gear adhering to the spec will be able to work in any type of network, private or public, domestic or global.
Two scenarios are covered by the timing discussion. The first is when all the inverse multiplexing links are synchronous--that is, when the timing on all the T1/E1 links within a group is derived from the same clock. This would be the case if all the circuits began and terminated in the same country (since each country supplies a master clock from which all circuits--even those from different carriers--derive their timing).
The second scenario involves non-synchronous links--when links in the group don't share a master clock. This might be the case if the circuits were routed through dif ferent countries.
Within these two scenarios there are a number of sub-classifications. Take the synchronous case, for example. All the links might be transparent--that is, the user (and not the network) provides the timing. Such a scenario is typical of private networks.
Here, two options are possible. One is master-master, in which the IMA device acts as the clock source and the timing of both ends of the link group are independent. This requires that the IMA device be able to support a timing accuracy of 1.544 Mbit/s +/-32 ppm for a T1 configuration and 2.048 Mbit/s +/-50 ppm for an E1 configuration.
A more common setup under the transparent link scenario is master-slave. One IMA device acts as the master and drives the timing of the T1 or E1 links; the other acts as slave and synchronizes its timing source from its received T1/E1 signals.
A synchronous network might also involve non-transparent links, those in which the network takes care of the clocking. In such cases, an IMA device should be able to operate in a single synchronization hierarchy (a single time domain) or more than one digital hierarchy (two or more timing domains). A single time domain is one in which the timing comes from a single source--this is typically the case when all the circuits have been purchased from the same provider.
Also, the IMA access device should be capable of operating when two or more carriers are furnishing the links. Net managers are likely to go with this kind of configuration in order to achieve route diversity; they might, for example, choose to purchase two T1 lines from one carrier and two from another. Since each carrier has its own synchronization hierarchy, each link is synchronized to a different master clock. In this case, the IMA access device picks a source from which to derive its clocking and compensates for the differences between that source and the others.
Clocking is even more complicated when inverse multiplexing is operating across international bounda ries or interexchange carrier topologies. Here, each of the individual trunk receivers must be able to implement controlled frame slippage to compensate for the timing differences between circuits. But doing so could actually create other problems for inverse multiplexing, since partial cells might have to be removed from the stream in order to keep the frames in sync by re-initiating the IMA framing process. If this happens, the best solution is to use unsynchronized trunks instead.
Add dial-up support to the mix and timing gets hairier still. The IMA device has to be able to operate not only in an unsynchronized environment with multiple timing domains, but may also have to work in a hybrid (mixed public/private) network.
Although the forum has made a great deal of progress with the IMA spec, some issues still remain to be resolved. For example, the inverse multiplexing round-robin protocol introduces cell delay variation. It's something the sub-working group is looki ng to minimize. The group also will try to wrap up work on details of the IMA MIB, which will permit IMA devices to be managed as part of the overall network.
The goal? Have the final version of the IMA spec ready for straw vote at the ATM Forum's August meeting; a final vote is expected by the end of 1996.
But standardization's not the whole story. Something that remains to be seen is how the spec will wind up being implemented. Are vendors more likely to build standalone products or work the spec into products already being made? Either way, the answer will affect how net managers design their networks.
Members of the ATM Forum can retrieve a copy of the IMA spec from http://www.atmforum.com/AFPHY/95-1121R3.
[ Home ]
[
Registration
|
Subscriptions
]
[
Contact Us
|
E-Mail
]
|
|||||||||||
|
|||||||||||
|
 |
|
|
