BFD for MPLS TE

Background

In most cases, MPLS TE uses TE FRR, CR-LSP backup, and TE tunnel protection group to enhance network reliability. These technologies detect faults using the RSVP Hello or RSVP Srefresh mechanism, but the detection speed is slow. When a Layer 2 device such as a switch or hub exists between two nodes, the traffic switchover speed is even slower, leading to traffic loss. BFD uses the fast packet transmission mode to quickly detect faults on MPLS TE tunnels, so that a service traffic switchover can be triggered quickly to better protect the MPLS TE service.

Concepts

Based on BFD session setup modes, BFD is classified into the following types:

• Static BFD: Local and remote discriminators of BFD sessions are manually configured.

• Dynamic BFD: Local and remote discriminators of BFD sessions are automatically allocated by the system.

For details about BFD, see BFD Configuration in the S2720, S5700, and S6700 V200R019C10 Configuration Guide - Reliability.

Implementation

BFD for RSVP

When Layer 2 devices exist between neighboring RSVP nodes, the two nodes can detect a link failure based only on the RSVP Hello mechanism. Several seconds are required to complete a switchover. This results in the loss of a great deal of data.

BFD for RSVP detects faults in milliseconds on links between RSVP neighboring nodes. BFD for RSVP applies to the TE FRR networking where Layer 2 devices exist between the PLR and its RSVP neighbor along the primary CR-LSP, as shown in Figure 1.

Figure 1 BFD for RSVP

BFD for RSVP can share BFD sessions with BFD for OSPF, BFD for IS-IS, or BFD for Border Gateway Protocol (BGP). Therefore, the local node selects the minimum parameter values among the shared BFD session as the local BFD parameters. The parameters include the transmit interval, the receive interval, and the local detection multiplier.

BFD for CR-LSP

BFD for CR-LSP can rapidly detect faults on CR-LSPs and notify the forwarding plane of the faults to ensure a fast traffic switchover. BFD for CR-LSP usually works with a hot-standby CR-LSP or tunnel protection group.

A BFD session is bound to a CR-LSP. That is, a BFD session is set up between ingress and egress nodes. A BFD packet is sent by the ingress node and forwarded to the egress node along a CR-LSP. The egress node then responds to the BFD packet. The BFD session at the ingress node can rapidly detect the status of the path through which the LSP passes.

Upon detecting a link failure, BFD notifies the forwarding plane of the failure. The forwarding plane searches for a backup CR-LSP and switches traffic to it. The forwarding plane then reports fault information to the control plane. If dynamic BFD for CR-LSP is used, the control plane creates a BFD session for the backup CR-LSP. If static BFD for CR-LSP is used, a BFD session can be configured for the backup CR-LSP.

Figure 2 BFD for CR-LSP before and after a link fault occurs

BFD for TE Tunnel

BFD detects faults in the entire TE tunnel and triggers traffic switchovers for VPN applications such as VPN FRR.

BFD for CR-LSP notifies a TE tunnel of faults and triggers service switchovers between CR-LSPs in the TE tunnel. Unlike BFD for CR-LSP, BFD for TE tunnel notifies VPN applications of faults and triggers service switchovers between TE tunnel interfaces.

Differences