Types of Protection

This section provides an overview of the three different types of protection schemes.

Protection can be broken into

• Path protection (sometimes called end-to-end protection)

• Local protection, which can be broken into two types:

  - Link protection

  - Node protection

Path Protection

Path protection is not currently available on Cisco routers. It is provided here for the sake of completeness and is not discussed further in this chapter. It is, however, discussed again in Chapter 9, “Network Design with MPLS TE,” where the scalability of path protection is compared with that of link and node protection.

Path protection is essentially the establishment of an additional LSP in parallel with an existing LSP, where the additional LSP is used only in case of failure. This LSP is sometimes called the backup, secondary, or standby LSP. The backup LSP is not used to carry traffic except during a failure condition—hence, the term standby.

The backup LSP is built along paths that are as diverse as possible from the LSP they're protecting. This ensures that a failure along the path of the primary LSP does not also affect the backup LSP. Path protection is simple in concept. Each primary LSP is backed up by a standby LSP. Both the primary and backup LSPs are configured at the headend. Both are signalled ahead of time in the control plane.

The primary and backup LSPs might have the same constraints. If the primary LSP has a bandwidth reservation of 100 Mbps, the backup LSP can also reserve 100 Mbps. This way, the end-to-end characteristics essentially remain the same, no matter whether the LSP used to carry traffic is the primary LSP or the protection LSP.

As mentioned in the preceding section, simply having a second path option under the tunnel interface does not make it path protection—it would be an LSP reroute. Path protection has better convergence than IGP convergence in an IP network or MPLS TE LSP reroute because it makes use of a presignalled LSP that is ready to go in case the primary LSP fails. With path protection, the relationship between the backup LSP and the number of primary LSPs it is protecting is 1:1. This makes the path protection scheme less scalable.

In other words, for every LSP you want to protect, you have to signal another LSP. If you want the primary and backup LSPs to share the same bandwidth characteristics, they need to reserve the same amount of bandwidth. Protection LSPs kick in only when there's a failure, and hopefully your network failure rate is far less than 50 percent, so you end up reserving backup bandwidth that you won't use most of the time and keeping other LSPs in the network from being able to use that bandwidth.

Figure 7-1 shows a primary tunnel going from 7200a to 7200c over 12008a and 12008c. The path protection tunnel is also from the headend 7200a to tail 7200c but goes over a diverse path (7200a→7500a→12008b→12008d→7500c→7200c).

Local Protection

Local protection is the term used when the backup or protection tunnel is built to cover only a segment of the primary LSP. Local protection, like path protection, requires the backup LSP to be presignalled.

In local protection, the backup LSP is routed around a failed link (in link protection) or node (in node protection), and primary LSPs that would have gone through that failed link or node are instead encapsulated in the backup LSP. Local protection has several advan-tages over path protection—faster failure recovery, 1:N scalability, and the consumption of less network state, to name a few.

Local Protection Terminology

Cisco's implementation of local protection is based on the bypass section of the IETF draft-ietf-mpls-rsvp-lsp-fastreroute, “Fast Reroute Extensions to RSVP-TE for LSP Tunnels,” which might be an RFC by now.

Unlike path protection, for local protection, the relationship between the backup LSP and the number of primary LSPs it is protecting is 1:N. In other words, a single backup LSP can protect N primary LSPs, making it more scalable than path protection. This scalability makes the local protection scheme extremely attractive.

Before going any further into local protection, it is important to stop and understand some of the terminology. Figure 7-2 shows 12008a as the headend as of two backup tunnels—tunnel0, which terminates on 12008c, and tunnel1, which terminates on 7200c. Table 7-1 defines some of the commonly used terms.

Table 7-1. Local Protection Terminology

Term	Definition
PLR	Point of Local Repair—The headend of the backup tunnel. In Figure 7-2, 12008a is the PLR.
MP	Merge Point—The merge point is where the backup tunnel terminates. In Figure 7-2, the merge point for tunnel0 is 12008c, and the merge point for tunnel1 is 7200c.
NHop	Next-hop router—A router that is one hop away from the PLR. This bypasses the protected link (12008a→12008c). 12008c in Figure 7-2 is the NHop for PLR 12008a.
NNHop	Next-next-hop router—A router that is two hops away from the PLR. 7200c is the NNHop for PLR 12008a in Figure 7-2. The NNHop bypasses a protected node (12008c).

In addition to the terms “backup tunnel” and “protection tunnel,” you might see the terms “FRR tunnel” and “bypass tunnel” being used to refer to this presignalled tunnel. They all mean the same thing.

The Need for Label Stacking

Consider Figure 7-3. It has two tunnels: primary and backup. The primary tunnel goes from 7200a to 7200c, whereas the backup tunnel goes from 12008a to 12008c, protecting link 12008a→12008c. Labels are distributed downstream to upstream (from 7200c toward 7200a). For the primary tunnel, routers 7200a, 12008a, and 12008c receive labels 16, 33, and POP (implicit null), respectively, in RSVP Resv messages from their downstream neighbors. Similarly for the backup tunnel, 12008a receives label 38 from 12008b. 12008b receives label 35 from 12008d, and 12008d receives the POP label from 12008c.

In the forwarding plane, when the ingress router 7200a forwards a packet down the primary tunnel, it imposes a label of 16 and transmits the packet to 12008a. 12008a label-swaps 16 to 33 and sends it to 12008c. Because 12008c performs Penultimate Hop Popping (PHP), the top label 33 is removed, and the packet is sent to 7200c, which is the egress router.

If you now focus your attention on the link 12008a→12008c (the protected link), you'll notice that primary tunnel packets that are carried on this link have a label value of 33 as they enter 12008c.

Now consider Figure 7-4.

Before the protected link failed, the primary tunnel traffic entered 12008a with a label of 33.

When the protected link fails, if the primary tunnel traffic entering 12008a somehow reached 12008c with a label of 33, it would be as though the protected link never failed. 12008c would simply POP label 33 and send the packet to 7200c. This is because all routers in this figure are allocating labels from global label space. One of the benefits of global label space is that a router does the same thing with a label no matter what interface it comes in on.

This is exactly what happens with local protection. Because the backup tunnel is presignalled and is ready to carry traffic to 12008c, when the protected link fails, 12008a switches the traffic onto the backup path. Because 12008c is expecting the packets to arrive with a label value of 33, 12008a takes the packets destined for 12008c with a label value of 33 and stacks another label, 38, on top.

Label 38 is what 12008a is expected to impose on any packets entering the backup tunnel. As you can see in Figure 7-4, the packet leaving 12008a toward 12008b has a label stack {38,33}. As you'd expect, 12008b switches the packet based on the top-level label, 38. The packet leaving 12008b now has a label stack of {35,33} because 12008b label swapped the top label, 38, with label 35. When this packet reaches 12008d, PHP is performed, removing the top label. 12008d performs PHP for the backup tunnel. With the top label removed, the packet has a single label of 33 as it enters 12008c. From the labels exchanged for the primary tunnel, 12008c performs PHP when it receives packets with a label of 33, and the packet is forwarded to 7200c.

Notice that the packet with label 33 enters 12008c over a different interface than it would have if the protected link did not go down. This is not an issue for 12008c because it is using global label space. 12008c does not care on which interface the packet enters. If it comes in with a label value of 33, it performs PHP and forwards the packet to 7200c. As you can see, for this scheme to work, both label stacking and global label space are required.

The other assumption made in local protection is that the failure is temporary. 12008a forwards the traffic down the backup tunnel upon failure and then informs the primary tunnel's headend (7200a) of the failure and its subsequent protection. 7200a then performs a make-before-break headend LSP reroute using normal CSPF.

As previously mentioned, there are two types of local protection—link protection and node protection. They're similar in concept, but node protection is more complex than link protection.

This section briefly summarizes link and node protection. The rest of this chapter examines each of them in more detail.

Link Protection Overview

In many networks that are deployed today, it is common to see high-bandwidth links carrying traffic belonging to “important” flows and other flows that are not so important. If MPLS TE is deployed in such networks, “important flows” translates to “important LSPs.” These LSPs might be carrying critical information or time-sensitive data that requires a real-time response. In such cases, it would be nice if all the “important LSPs” could be protected while ignoring the less-important LSPs. FRR allows you to protect some of your TE tunnels (just the ones you deem important) or all of your TE tunnels. With link protection, you can protect links that are carrying these important LSPs by using presignalled backup tunnels that bypass the protected link. Figure 7-5 depicts one such sample network.

Here, link 12008a→12008c is considered the crucial link over which a primary tunnel is signalled. This link is called the protected link. In order to protect this link and the primary tunnel over it, a backup tunnel is signalled around the link so that the headend of the backup tunnel is the node that is immediately upstream of the protected link, and the tail of the backup tunnel is the node that is immediately downstream of the protected link. In Figure 7-5, the headend of the backup tunnel is 12008a (PLR), and the tail is 12008c (MP). As described in the preceding section, when the protected link fails, label stacking delivers the primary tunnel packets to 12008c so that 12008c sees the label it is expecting. Link protection relies on the fact that, although a protected link has gone down, the router at the other end of that protected link is still up. Link protection uses NHop backup tunnels; the backup tunnels terminate on the node on the other end of the protected link. As you can imagine, this allows you to protect against a link failure but not a node failure. If the node you terminate your backup tunnel on goes down, link protection can't help you.

Node Protection Overview

What if the node that is downstream of the protected link goes down, causing the protected link to fail? If this happens, it does you no good to try to deliver the packets to the node that just went down. In this case, you might want to safeguard the primary LSP from node failure on the other end of a link in addition to protecting the link itself.

Looking at this slightly differently, if you protect against failure of the downstream node, you have automatically protected against failure of the downstream link as well. Figure 7-6 shows the protection being moved to 12008c. 12008a is still the PLR, but the MP is now 7200c instead of 12008c. Node protection uses NNHop backup tunnels instead of NHop tunnels because it needs to protect against a failure of the NHop.

Node protection is similar to link protection in most ways. It differs from link protection in that the MP is not the NHop, but the NNHop. This has implications in label stacking as well. With link protection, the PLR knows what label the MP expects because it receives a label mapping directly from the MP for the primary tunnel. With node protection, however, the label the MP wants to see is never signalled through RSVP to the PLR. There has to be some other mechanism to learn about the label that MP is expecting for the primary tunnel. This mechanism is discussed in detail in the later section “Node Protection.”

Link Versus Node Protection

Link and node protection scale differently, solve different problems, and have different restrictions. You don't always need to protect everything in your network. You might want to protect only resources you consider critical (perhaps only the most important core links) or consider protecting links that are not being protected by, say, APS. Perhaps you need to protect LSPs carrying Voice over IP (VoIP) traffic or specific types of traffic from specific customers with whom you have service-level agreements (SLAs).

Where you deploy protection, and what type of protection you deploy, is up to you. Whatever you end up doing, you need to understand the scalability of various protection schemes as part of deciding what to protect. See Chapter 9 for a discussion of protection scalability.

The next two sections examine link and node protection in more detail—how they work, how they're configured, and the differences between them.

All the figures in this chapter are based on the sample network shown in Figure 7-7. The router IDs (RIDs) (also loopback addresses) are in parentheses above or below the routers. For example, 7200a's RID is 4.4.4.4.

Each link's subnet address is of the form 10.0.x.y, and each link has a 24-bit mask. For example, the link between 7200a and 12008a is 10.0.3.0/24. The IP address of 7200a's side of the link is 10.0.3.4 because 7200a's RID is 4.4.4.4, and 12008a's side of the link has the address 10.0.3.5 because 12008a's RID is 5.5.5.5.