The ATM Forum's upcoming LANE Version 2.0 will provide redundancy for LANE services. The February 1995 LANE 1.0 specification doesn't provide details for LANE redundancy, but from an implementation perspective it doesn't prohibit redundancy. Under LANE 1.0, vendors have implemented methods of providing LANE redundancy that may or may not interoperate -- even though they provide the same form of redundancy.
One of the most common forms of LANE redundancy allows each LES to be made aware of all the other LANE servers on the same emulated LAN (e-LAN). When this occurs, the LESes are said to be operating as "cooperating pairs." Of course, the ATM devices running LANE services must be able to support redundant LES/BUS pairs.
The figure
"Redundancy for Emulated LANs"
illustrates ho
w redundant LES/BUS pairs can be configured. Notice that LAN emulation client (LEC) A is served by LES/BUS pair 1, LEC B is served by LES/BUS pair 2, and LEC C is served by LES/BUS pair 3. In reality, multiple LECs can and usually are supported by a single LES/BUS pair. However, for simplicity we have shown only one LEC per LES/BUS pair.
Cooperating LES devices use point-to-multipoint connections from each LES to each of the other LES pairs associated with that particular e-LAN. As can be seen from the figure, there is a point-to-multipoint connection from LES 1 to LES 2 and LES 3. Similarly, LES 2 has point-to-multipoint connections to LES 1 and LES 3. And LES 3 has a point-to-multipoint connection to LES 1 and LES 2. Using the point-to-multipoint connections, each LES becomes aware of the other LES servers on its e-LAN and can exchange information with them. Since the same configuration information exists in all the cooperating LANE servers, should one of the LES/BUS devices fail, another pair simply
takes over for the failed device. The same redundancy occurs if a cable feeding a LES/BUS device is cut.
For clarity, the figure shows only the connections to the LANE servers. However, the same kind of redundancy is usually done for the BUS as well. Each BUS has point-to-multipoint connections to all the other BUS pairs in the e-LAN. Should one BUS fail, another can take its place.
Fault-Recovery Times
In connectionless networks like Ethernet, every packet is routed individually. This makes fault recovery easy and rapid. However, ATM relies on calls placed through virtual channel connections (VCCs) to move data through the network. When a disruption occurs, the switches in an ATM network must reroute the existing calls. This takes time. Also, the ATM network has to deal with more than one call type. Some calls are set up over a data-direct VCC. The data-direct VCC carries unicast user data. That is, the VCC acts as a typical data circuit, much like a telephone connection. Other calls are
set up over control-direct or configure-direct VCCs. These VCCs are primarily used for LANE services and broadcasts. They are analogous to the telephone system's control infrastructure that helps route calls from the calling to the called party. These VCCs typically support connections to the LES and BUS.
When a network outage interrupts only the data-direct VCCs, recovery times tend to be rapid. This is because the control- and configure-direct VCCs are still alive, so the LANE services themselves are unaffected by the outage. All that is required is reconnecting the data-direct calls, a fairly straightforward process.
However, when control- or configure-direct VCCs are disrupted, the LANE services themselves are interrupted. The LANE clients that lose LANE services make a graceful (we hope) exit from the ATM network. Before the data-direct calls can be restored, the LANE clients must reconnect with the appropriate LES/BUS and reregister with the LANE services. This process takes considerably lo
nger than simply reconnecting data-direct calls.
The good news is that in either case the recovery will be rapid, depending on which links are disrupted and how many switches are involved. In a typical backbone network, calls can be restored in under 30 seconds. For network outages, that's a very respectable amount of time.
Bridge Loops
Loops occur when there are multiple paths from a source to a destination in a bridged environment. Bridge loops are nasty: They cause traffic storms that can easily bring an entire enterprise network to its knees. Keep in mind that redundant links, if not properly configured, can become bridge loops.
In LANE version 1.0, everything within an e-LAN is bridged. This makes it easy to accidentally create loops since, in providing redundancy, we are indeed creating multiple parallel paths. However, there are steps that can be taken to eliminate bridge loops.
Some ATM switches support the IEEE 802.1d Spanning Tree protocol. Spanning Tree was develope
d specifically to prevent bridge loops. It does this by assigning path costs to parallel links. Simply put, the Spanning Tree algorithm automatically turns off the switch or bridge ports on parallel links with the highest path cost. This disables the parallel paths and prevents looping. If the primary link fails, the algorithm turns back on the port connecting the redundant path.
Unfortunately, not every ATM switch supports Spanning Tree. However, even in these switches, looping can be avoided. Suppose switch A in the figure
"Redundant Connections Without Loops"
is told that the cost to switch B over fiber A is zero. However, the cost to B through alternative paths, such as fibers D and C or B and E, is 10 or 15, respectively. Since the redundant paths are associated with higher costs, they will not be used unless the primary path does not exist. Therefore looping is less likely to occur. The cost values are configured on a port-connection basis by the network administrator. No mat
ter what method you choose, the goal is to have redundant paths stay dormant until the main paths fail.
Proactive Monitoring
It is easy to become overly reassured by networks designed with a high degree of redundancy. However, this false sense of assurance can be dangerous. More than a few network managers have been surprised when their already wrapped FDDI rings suffered an additional failure. Sadly, these managers were blissfully unaware of the original wrap until the network was neatly sliced into two by the second failure.
Clearly, quick action must be taken to correct the initial situation, particularly if the network's redundancy masks a serious problem. The staff should proactively monitor the network's health to ensure that it is fully functional. This means regular and careful checks on fiber connections, switches, routers, and ATM end-stations. Suffice it to say that monitoring the network's state with management tools such as SNMP or Integrated Local Management Interface is ess
ential.
Surviving Loss
ATM networks can be built with the ability to survive the loss of multiple cables and multiple switches. Combining redundant, cooperating LES/BUS services with full-meshed and dual-homed cabling provides a high degree of survivability to any ATM network. This means that even with its connection-oriented, point-to-point and point-to-multipoint configuration, an ATM backbone can still be made bulletproof. Should an ATM switch go down, or a cable feeding it fail, the network will survive.
illustration_link (23 Kbytes)
Redundant LES/BUS pairs provide load sharing and eliminate single-point
failures.
illustration_link (16 Kbytes)
Loops can be eliminated by specifying preferred routes among the switches.
Jeffrey Fritz (
jfritz@wvu.edu
) is responsible for advanced network technology at West Virginia University. He is the author of Remote LAN Access: A Guide for Networkers and the Rest of Us (Manning Publications/Prentice-Hall PTR) and Sensible ISDN Data Applications (West Virginia University Press).
Bulletproofing ATM, Part 2
