| < Day Day Up > |
|
In a network, there are several potential points of failure. Two major types of failures are link failure and node failure (see Figure 4.6). Minor failures could involve switch hardware, switch software, switch databases, and/or link degradation.
Figure 4.6: Network Failures
The telecommunications industry has historically addressed link failures with two types of fault-tolerant network designs: one-to-one redundancy and one-to-many redundancy. Another commonly used network protection tactic employs fault-tolerant hardware.
To protect an MPLS network, you could preprovision a spare path with exact QoS and traffic-processing characteristics. This path would be spatially diverse and would be continually exercised and tested for operations. However, it would not be placed online unless there was a failure on the primary protected path. This method, known as one-to-one redundancy protection (see Figure 4.7), yields the most protection and reliability, but the cost of its implementation can be extreme.
Figure 4.7: One-to-One Redundancy
A second protection scheme is one-to-many redundancy protection. Using this method, the backup path takes over when one path fails. The network shown in Figure 4.8 can handle a single path failure but not two path failures.
Figure 4.8: One-to-Many Redundancy
A third protection method is the use of fault-tolerant switches (see Figure 4.9). In this design, every switch features built-in redundant functions—from power supplies to network cards. Figure 4.9 shows redundant network cards with a backup controller. Note that the one item in common, and not redundant, is the cross-connect table. If switching data becomes corrupt, fault-tolerant hardware cannot address the problem.
Figure 4.9: Fault-Tolerant Equipment
Now that we have examined the three network protection designs (one-to-one, one-to-many, and fault-tolerant hardware) and two methods for detecting a network failure (heartbeat and error message), we need to talk about which layers and protocols are responsible for fault detection and recovery.
Given that the further the data progresses up the OSI stack, the longer that its recovery will take, it makes sense to attempt to detect failures at the physical level first.
MPLS could rely on the Layer 1 or Layer 2 protocols to perform error detection and correction. MPLS could either run on a protected SONET ring or use ATM and Frame Relay fault-management programs for link and path protection. In addition to the protection that MPLS networks could secure via SONET, ATM, or Frame Relay, IP has its recovery mechanisms in routing protocols like OSPF or IGP.
With all these levels of protection already in place, why does MPLS need additional protection? Because there is no protocol that is responsible for ensuring the quality of the link, tunnel, or call placed on an MPLS link. The MPLS failure-recovery protocol must not only perform rapid switching, it must also ensure that the selected path is prequalified to handle traffic loads while maintaining QoS conditions. If traffic loads become a problem, MPLS must be able to offload lower-priority traffic to other links.
Knowing that MPLS must be responsible for sending traffic from a failed link to a link of equal quality, let’s look at two error-detection methods as they apply to MPLS.
Checkpoint | Answer the following questions.
Answers: 1. 60 milliseconds; 2. the heartbeat method and the error-message method; 3. increased overhead functions as well as reduced routing time when rerouting network traffic; 4. link failure and node failure. |
| < Day Day Up > |
|