RFC 5884

Bidirectional Forwarding Detection (BFD) for MPLS Label Switched Paths (LSPs)

📅 published June 2010, from ietf

RFC 5884: Bidirectional Forwarding Detection (BFD) for MPLS Label Switched Paths (LSPs) 🦋

Title block, the important bits:

  • Number: RFC 5884
  • Stream: Internet Engineering Task Force (IETF)
  • Authors: R. Aggarwal, K. Kompella (both Juniper Networks), T. Nadeau (BT), and G. Swallow (Cisco Systems, Inc.)
  • Category: Standards Track
  • ISSN: 2070-1721
  • Date: June 2010
  • Updates: RFC 1122

Abstract ✨

okay so the big idea here is using Bidirectional Forwarding Detection (BFD) to catch when an MPLS Label Switched Path (LSP) breaks on the data plane 🫶. LSP Ping is already a thing for that, and it can also check that the data plane matches what the control plane thinks is happening. BFD can do the first job but not the second one 💅. The good news is that BFD Control packets need way less control plane processing than LSP Ping messages do. So pairing LSP Ping with BFD can get you faster data plane failure detection, and/or let you cover more LSPs at once 🔥. This document explains when BFD makes sense alongside LSP Ping, and it walks through the procedures for doing that 💖.

Status of This Memo 🌸

This is an Internet Standards Track document.

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has had public review and has been approved for publication by the Internet Engineering Steering Group (IESG). More info about Internet Standards is in Section 2 of RFC 5741.

For the latest status of this document, any errata, and how to send feedback, check http://www.rfc-editor.org/info/rfc5884.

Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please read these documents carefully, because they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they are provided without warranty as described in the Simplified BSD License.

This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.

Table of Contents 🎀

1. Introduction ....................................................3
2. Specification of Requirements ...................................3
3. Applicability ...................................................3
   3.1. BFD for MPLS LSPs: Motivation ..............................3
   3.2. Using BFD in Conjunction with LSP Ping .....................5
4. Theory of Operation .............................................6
5. Initialization and Demultiplexing ...............................7
6. Session Establishment ...........................................7
   6.1. BFD Discriminator TLV in LSP Ping ..........................8
7. Encapsulation ...................................................8
8. Security Considerations .........................................9
9. IANA Considerations ............................................10
10. Acknowledgments ...............................................10
11. References ....................................................10
   11.1. Normative References .....................................10
   11.2. Informative References ...................................10

1. Introduction 🧚

Okay so one really desirable use of BFD is keeping track of whether a Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) is still alive 💖. Specifically, BFD can spot a data plane failure in the forwarding path of an MPLS LSP. LSP Ping [RFC4379] is already an existing mechanism for catching MPLS LSP data plane failures, and for checking the MPLS LSP data plane against the control plane 🔍. This document covers how BFD fits in alongside LSP Ping for detecting MPLS LSP data plane failures, and it also lays out the procedures for using BFD to detect those failures 💅✨.

2. Specification of Requirements 📜

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

3. Applicability 🦋

So, if an MPLS LSP stops delivering data traffic, the control plane might not be able to tell you what went wrong 🙈. For example, the control plane of the LSP could be perfectly fine while the data plane is misforwarding or dropping packets. That's why we need a way to detect data plane failures in the MPLS LSP path [RFC4377] 🫶.

3.1. BFD for MPLS LSPs: Motivation 💜

LSP Ping, described in [RFC4379], is already an existing way to detect an MPLS LSP data plane failure 🔍. On top of that, LSP Ping can check the MPLS control plane against the data plane too. It does this by making sure the LSP maps to the same Forwarding Equivalence Class (FEC) at the egress as it does at the ingress 💅.

BFD can't be used to verify the MPLS control plane against the data plane 🙅‍♀️. But BFD can detect a data plane failure in the forwarding path of an MPLS LSP ✨. The LSP might be associated with any of the following FECs:

  • a) Resource Reservation Protocol (RSVP) LSP_Tunnel IPv4/IPv6 Session [RFC3209]
  • b) Label Distribution Protocol (LDP) IPv4/IPv6 prefix [RFC5036]
  • c) Virtual Private Network (VPN) IPv4/IPv6 prefix [RFC4364]
  • d) Layer 2 VPN [L2-VPN]
  • e) Pseudowires based on PWid FEC and Generalized PWid FEC [RFC4447]
  • f) Border Gateway Protocol (BGP) labeled prefixes [RFC3107]

LSP Ping does a LOT of control plane verification 🧐. BFD, on the other hand, was designed as a lightweight way to test just the data plane 🪶. Because of that, LSP Ping is more computationally expensive than BFD for detecting MPLS LSP data plane faults 💸. BFD also fits better in hardware or firmware, since its packet format is fixed 🔧. So using BFD for detecting MPLS LSP data plane faults has these advantages:

  • a) Support for fault detection on a greater number of LSPs 🌈.
  • b) Fast detection 🏎️💨. Detection with sub-second granularity is considered fast detection. LSP Ping is meant for environments where fault detection messages are exchanged either for diagnostics or for infrequent periodic fault detection, on the order of tens of seconds or minutes. So it isn't appropriate for fast detection. BFD, on the other hand, is designed for sub-second fault detection intervals. Here are some possible cases where fast detection may be desirable for MPLS LSPs:
    1. A bypass LSP used for facility-based link or node protection [RFC4090] 🛡️. Here the bypass LSP is basically an alternate link protecting one or more LSPs. It represents an aggregate and carries data traffic belonging to one or more LSPs when the protected link or node fails. So fast failure detection of the bypass LSP may be desirable, especially when a link or node fails and the data traffic moves over to the bypass LSP.
    2. MPLS Pseudowires (PWs) 🍓. Fast detection may be wanted for MPLS PWs, depending on i) the model used to layer the MPLS network with the Layer 2 network, and ii) the service the PW is emulating. For a non-overlay model between the Layer 2 network and the MPLS network, the provider may rely on PW fault detection to give service status to the end-systems. Also, in that case, interworking scenarios such as ATM/Frame Relay interworking may force periodic PW fault detection messages. Depending on the requirements of the service the MPLS PW is emulating, fast failure detection may be desirable.

There may be other cases where fast failure detection is wanted for MPLS LSPs too 🌸.

3.2. Using BFD in Conjunction with LSP Ping 🫶

BFD can be used for MPLS LSP data plane fault detection 💖. But it doesn't have all the functionality of LSP Ping. In particular, it can't be used to verify the control plane against the data plane 🙅‍♀️. LSP Ping does the following things that are outside the scope of BFD:

  • a) Association of an LSP Ping Echo request message with a FEC. With Penultimate Hop Popping (PHP), or when the egress Label Switching Router (LSR) hands an explicit null label to the penultimate hop router, for a single label stack LSP, the only way to tie a fault detection message to a FEC is to carry the FEC in the message. LSP Ping provides this. Next-hop label allocation also makes it necessary to carry the FEC in the fault detection message, because the label alone isn't enough to identify the LSP being verified. On top of that, having the FEC in the Echo request message makes it possible to verify the control plane against the data plane at the egress LSR 🔎.
  • b) Equal Cost Multi-Path (ECMP) considerations. LSP Ping traceroute makes it possible to probe multiple alternate paths for LDP IP FECs 🛤️.
  • c) Traceroute. LSP Ping supports traceroute for a FEC, and it can be used for fault isolation 🕵️‍♀️.

So BFD is used together with LSP Ping for MPLS LSP fault detection, like this 👑:

  • i) LSP Ping is used to bootstrap the BFD session, as described later in this document 🥾.
  • ii) BFD is used to exchange fault detection (i.e., BFD session) packets at the required detection interval ⏱️.
  • iii) LSP Ping is used to periodically verify the control plane against the data plane, by making sure the LSP maps to the same FEC at the egress as it does at the ingress 🔁.

4. Theory of Operation ✨

okay so bestie, to use BFD for fault detection on an MPLS LSP, a BFD session MUST be established for that particular MPLS LSP 🫶. BFD Control packets MUST be sent along the same data path as the LSP being verified, and the egress LSR's BFD processing module is who handles them 💅. If the LSP is tied to multiple FECs, a BFD session SHOULD be established for each FEC. This can happen with next-hop label allocation 🦋. So the whole operation is conceptually similar to the data plane fault detection procedures of LSP Ping. It's giving sibling energy 👯‍♀️

Now the fast-reroute drama 😭. If MPLS fast-reroute is being used for the MPLS LSP, BFD fault detection can cause false fault detections if the BFD fault detection interval is less than the MPLS fast-reroute switchover time. When fast-reroute gets triggered by a link or node failure, BFD Control packets get dropped until traffic is switched over to the backup LSP. If the switchover takes longer than the BFD fault detection interval, a fault gets declared even though the MPLS LSP is being locally repaired 🙈. To avoid this, the BFD fault detection interval should be greater than the fast-reroute switchover time. An implementation SHOULD provide configuration options to control the BFD fault detection interval 🔥.

If there are multiple alternate paths from an ingress LSR to an egress LSR for an LDP IP FEC, LSP Ping traceroute MAY be used to figure out each of these alternate paths 🧚. A BFD session SHOULD be established for each alternate path that gets discovered 💜.

Periodic LSP Ping Echo request messages SHOULD be sent by the ingress LSR to the egress LSR along the same data path as the LSP 🌸. This is how the control plane gets periodically checked against the data plane. The idea is making sure the LSP is mapped to the same FEC at the egress as it is at the ingress, which is honestly iconic 👑. The rate of generating these LSP Ping Echo request messages SHOULD be significantly less than the rate of generating the BFD Control packets 🍓. An implementation MAY provide configuration options to control the rate of generating the periodic LSP Ping Echo request messages ✨.

To turn on the fault detection procedures in this document for a particular MPLS LSP, this document requires the ingress and egress LSRs to be configured 🎀. That includes configuration for supporting BFD and LSP Ping as specified here. It also includes configuration that lets the ingress LSR figure out the method the egress LSR uses to identify Operations, Administration, and Maintenance (OAM) packets. For example, this covers whether the Time to Live (TTL) of the innermost MPLS label needs to be set to 1 so the egress LSR can identify the OAM packet 🙃. For fault detection on MPLS PWs, this document assumes that the PW control channel type [RFC5085] is configured and that LSP Ping support is also configured 🦋.

5. Initialization and Demultiplexing 🌈

A BFD session may be established for a FEC associated with an MPLS LSP 💖. As described above, with PHP or when the egress LSR distributes an explicit null label to the penultimate hop router, or with next-hop label allocation, the BFD Control packet received by the egress LSR doesn't carry enough info to link it to a BFD session 😭. So the demultiplexing MUST be done using the remote discriminator field in the received BFD Control packet. How the BFD discriminators get exchanged for this purpose is covered in the next section 💅.

6. Session Establishment 🦋

A BFD session is bootstrapped using LSP Ping ✨. This specification only describes procedures for BFD asynchronous mode. BFD demand mode is outside the scope of this specification, and so is the use of the Echo function 🙅‍♀️. Starting fault detection for a particular <MPLS LSP, FEC> combination results in the exchange of LSP Ping Echo request and Echo reply packets, in ping mode, between the ingress and egress LSRs for that <MPLS LSP, FEC> 🔥. To establish a BFD session, an LSP Ping Echo request message MUST carry the local discriminator the ingress LSR assigned for the BFD session. That value MUST subsequently be used as the My Discriminator field in the BFD session packets the ingress LSR sends 💜.

When the egress LSR gets the LSP Ping Echo request message, it MUST send a BFD Control packet to the ingress LSR, as long as the FEC validation in that Echo request message succeeds 🫶. This BFD Control packet MUST set the Your Discriminator field to the discriminator it received from the ingress LSR in the LSP Ping Echo request message. The egress LSR MAY respond with an LSP Ping Echo reply message that carries the local discriminator it assigned for the BFD session 🌸. The local discriminator assigned by the egress LSR MUST be used as the My Discriminator field in the BFD session packets the egress LSR sends 🍓.

The ingress LSR follows the procedures in [BFD] to send BFD Control packets to the egress LSR in response to the BFD Control packets received from the egress LSR 🧚. The BFD Control packets from the ingress to the egress LSR MUST set the local discriminator of the egress LSR in the Your Discriminator field. The egress LSR uses the received Your Discriminator field to demultiplex the BFD session 👑. As mentioned above, the egress LSR MUST send Control packets to the ingress LSR with the Your Discriminator field set to the local discriminator of the ingress LSR. The ingress LSR uses that to demultiplex the BFD session 🎀.

6.1. BFD Discriminator TLV in LSP Ping 💅

LSP Ping Echo request and Echo reply messages carry a BFD discriminator TLV for the purpose of session establishment, as described above 🌈. IANA has assigned a type value of 15 to this TLV ✨. This TLV has a length of 4. The value contains the 4-byte local discriminator that the LSR sending the LSP Ping message associates with the BFD session 💖.

If the BFD session is not in UP state, the periodic LSP Ping Echo request messages MUST include the BFD Discriminator TLV 😭.

7. Encapsulation 📦

BFD Control packets sent by the ingress LSR MUST be encapsulated in the MPLS label stack that corresponds to the FEC for which fault detection is being performed 🦋. If the label stack has a depth greater than one, the TTL of the inner MPLS label MAY be set to 1. This may be necessary for certain FECs so the egress LSR's control plane can receive the packet [RFC4379] 🔥. For MPLS PWs, the presence of a fault detection message may alternatively be indicated by setting a bit in the control word [RFC5085] 💜.

The BFD Control packet sent by the ingress LSR MUST be a UDP packet with a well-known destination port of 3784 [BFD-IP] and a source port assigned by the sender as per the procedures in [BFD-IP] 🫶. The source IP address is a routable address of the sender 🌸. The destination IP address MUST be randomly chosen from the 127/8 range for IPv4 and from the 0:0:0:0:0:FFFF:7F00/104 range for IPv6, with one exception 🍓. If the FEC is an LDP IP FEC, the ingress LSR may discover multiple alternate paths to the egress LSR for this FEC using LSP Ping traceroute 🧚. In that case, the destination IP address used in a BFD session established for one of those alternate paths is the address in the 127/8 range for IPv4, or in the 0:0:0:0:0:FFFF:7F00/104 range for IPv6, discovered by LSP Ping traceroute [RFC4379] to exercise that particular alternate path 👑.

The motivation for using the 127/8 address range is the same as specified in Section 2.1 of [RFC4379]. This is an exception to the behavior defined in [RFC1122] 🙈.

The IP TTL or hop limit MUST be set to 1 [RFC4379] ⭐.

BFD Control packets sent by the egress LSR are UDP packets 🎀. The source IP address is a routable address of the replier 🦋.

The BFD Control packet sent by the egress LSR to the ingress LSR MAY be routed based on the destination IP address, as per the procedures in [BFD-MHOP] 🌈. If this is the case, the destination IP address MUST be set to the source IP address of the LSP Ping Echo request message that the egress LSR received from the ingress LSR 💖.

Or, the BFD Control packet sent by the egress LSR to the ingress LSR MAY be encapsulated in an MPLS label stack 🫶. In this case, the presence of the fault detection message is indicated as described above 💅. This may be the case if the FEC for which fault detection is being performed corresponds to a bidirectional LSP or an MPLS PW. It may also be the case when there is a return LSP from the egress LSR to the ingress LSR 🌸. In this case, the destination IP address MUST be randomly chosen from the 127/8 range for IPv4 and from the 0:0:0:0:0:FFFF:7F00/104 range for IPv6 🍓.

The BFD Control packet sent by the egress LSR MUST have a well-known destination port of 4784 if it is routed [BFD-MHOP], or it MUST have a well-known destination port of 3784 [BFD-IP] if it is encapsulated in an MPLS label stack 🧚. The source port MUST be assigned by the egress LSR as per the procedures in [BFD-IP] 👑.

⚠️ Heads up, bestie: once the BFD session for the MPLS LSP is UP, either end of the BFD session MUST NOT change the source IP address and the local discriminator values of the BFD Control packets it generates, unless it first brings down the session. This means an LSR MUST ignore BFD packets for a given session, demultiplexed using the received Your Discriminator field, if the session is in UP state and the My Discriminator or the Source IP address fields of the received packet don't match the values associated with the session 😭🔥

8. Security Considerations 🔒

Okay this part is SERIOUS, so read it carefully 🥺. Security considerations discussed in [BFD], [BFD-MHOP], and [RFC4379] apply to this document 💀. For BFD Control packets sent by the ingress LSR, or when the BFD Control packet sent by the egress LSR is encapsulated in an MPLS label stack, MPLS security considerations apply. These are discussed in [MPLS-SEC] 💜. When BFD Control packets sent by the egress LSR are routed, the authentication considerations discussed in [BFD-MHOP] should be followed 🫶.

9. IANA Considerations 📋

This document introduces a BFD discriminator TLV in LSP Ping 🌈. The BFD Discriminator has been assigned a value of 15 from the LSP Ping TLVs and sub-TLVs registry maintained by IANA ✨.

10. Acknowledgments 🫶

Huge thanks to Yakov Rekhter, Dave Katz, and Ina Minei for contributing to the discussions that formed the basis of this document and for their comments 💖. Thanks to Dimitri Papadimitriou for his comments and review 🌸. Thanks to Carlos Pignataro for his comments and review 👑.

11. References 📚

11.1. Normative References

  • [BFD] Katz, D. and D. Ward, "Bidirectional Forwarding Detection", RFC 5880, June 2010. 🦋
  • [BFD-IP] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, June 2010. 🌸
  • [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", RFC 4379, February 2006. ✨
  • [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 💅
  • [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989. 🍓

11.2. Informative References ✨

okay bestie, these are the informative refs 📚 they're the extra reading that backs up the spec without being required to implement it 🤓 (main character energy for the bibliography, no cap)

   [BFD-MHOP] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
              (BFD) for Multihop Paths", RFC 5883, June 2010.

   [RFC5085]  Nadeau, T., Ed., and C. Pignataro, Ed., "Pseudowire
              Virtual Circuit Connectivity Verification (VCCV): A
              Control Channel for Pseudowires", RFC 5085, December 2007.

   [RFC3209]  Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
              and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
              Tunnels", RFC 3209, December 2001.

   [RFC4090]  Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast
              Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090,
              May 2005.

   [RFC5036]  Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed.,
              "LDP Specification", RFC 5036, October 2007.

   [RFC4364]  Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
              Networks (VPNs)", RFC 4364, February 2006.

   [L2-VPN]   Kompella, K., Leelanivas, M., Vohra, Q., Achirica, J.,
              Bonica, R., Cooper, D., Liljenstolpe, C., Metz, E., Ould-
              Brahim, H., Sargor, C., Shah, H., Srinivasan, and Z.
              Zhang, "Layer 2 VPNs Over Tunnels", Work in Progress,
              February 2003.

   [RFC4447]  Martini, L., Ed., Rosen, E., El-Aawar, N., Smith, T., and
              G. Heron, "Pseudowire Setup and Maintenance Using the
              Label Distribution Protocol (LDP)", RFC 4447, April 2006.

   [RFC3107]  Rekhter, Y. and E. Rosen, "Carrying Label Information in
              BGP-4", RFC 3107, May 2001.

   [RFC4377]  Nadeau, T., Morrow, M., Swallow, G., Allan, D., and S.
              Matsushima, "Operations and Management (OAM) Requirements
              for Multi-Protocol Label Switched (MPLS) Networks", RFC
              4377, February 2006.

   [MPLS-SEC] Fang, L., Ed., "Security Framework for MPLS and GMPLS
              Networks", Work in Progress, October 2009.

Authors' Addresses 🫶

the authors, the people who actually wrote this 🧚 here's where you can find them, iykyk 💅

   Rahul Aggarwal
   Juniper Networks
   1194 N. Mathilda Ave.
   Sunnyvale, CA  94089
   USA

   EMail: rahul@juniper.net


   Kireeti Kompella
   Juniper Networks
   1194 N. Mathilda Ave.
   Sunnyvale, CA  94089
   USA

   EMail: kireeti@juniper.net


   Thomas D. Nadeau
   BT
   BT Centre
   81 Newgate Street
   London EC1A 7AJ
   UK

   EMail: tom.nadeau@bt.com


   George Swallow
   Cisco Systems, Inc.
   300 Beaver Brook Road
   Boxborough, MA  01719
   USA

   EMail: swallow@cisco.com
📦 where this page comes from