]> Bidirectional Forwarding Detection (BFD) for MPLS Label Switched Paths (LSPs) Juniper Networks
1194 N. Mathilda Ave. Sunnyvale, CA 94089 USA rahul@juniper.net
Juniper Networks
1194 N. Mathilda Ave. Sunnyvale, CA 94089 USA kireeti@juniper.net
BT
BT Centre 81 Newgate Street London EC1A 7AJ UK tom.nadeau@bt.com
Retired
swallow@tbd.com
Cisco Systems, Inc.
venggovi@cisco.com
One desirable application of Bidirectional Forwarding Detection (BFD) is to detect a Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) data plane failure. LSP Ping is an existing mechanism for detecting MPLS data plane failures and for verifying the MPLS LSP data plane against the control plane. BFD can be used for the former, but not for the latter. However, the control plane processing required for BFD Control packets is relatively smaller than the processing required for LSP Ping messages. A combination of LSP Ping and BFD can be used to provide faster data plane failure detection and/or make it possible to provide such detection on a greater number of LSPs. This document describes the applicability of BFD in relation to LSP Ping for this application. It also describes procedures for using BFD in this environment. This document obsoletes RFC5884 and RFC7726.
Introduction One desirable application of Bidirectional Forwarding Detection (BFD) is to track the liveness of a Multiprotocol Label Switching (MPLS) Label Switched Path (LSP). In particular, BFD can be used to detect a data plane failure in the forwarding path of an MPLS LSP. LSP Ping is an existing mechanism for detecting MPLS LSP data plane failures and for verifying the MPLS LSP data plane against the control plane. This document describes the applicability of BFD in relation to LSP Ping for detecting MPLS LSP data plane failures. It also describes procedures for using BFD for detecting MPLS LSP data plane failures.
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 .
Applicability In the event of an MPLS LSP failing to deliver data traffic, it may not always be possible to detect the failure using the MPLS control plane. For instance, the control plane of the MPLS LSP may be functional while the data plane may be mis-forwarding or dropping data. Hence, there is a need for a mechanism to detect a data plane failure in the MPLS LSP path .
BFD for MPLS LSPs: Motivation LSP Ping described in is an existing mechanism for detecting an MPLS LSP data plane failure. In addition, LSP Ping also provides a mechanism for verifying the MPLS control plane against the data plane. This is done by ensuring that the LSP is mapped to the same Forwarding Equivalence Class (FEC), at the egress, as the ingress. BFD cannot be used for verifying the MPLS control plane against the data plane. However, BFD can be used to detect a data plane failure in the forwarding path of an MPLS LSP. The LSP may be associated with any of the following FECs:
  • a) Resource Reservation Protocol (RSVP) LSP_Tunnel IPv4/IPv6
    Session
b) Label Distribution Protocol (LDP) IPv4/IPv6 prefix
c) Virtual Private Network (VPN) IPv4/IPv6 prefix d) Layer 2 VPN
  • e) Pseudowires based on PWid FEC and Generalized PWid FEC
f) Border Gateway Protocol (BGP) labeled prefixes
LSP Ping includes extensive control plane verification. BFD, on the other hand, was designed as a lightweight means of testing only the data plane. As a result, LSP Ping is computationally more expensive than BFD for detecting MPLS LSP data plane faults. BFD is also more suitable for being implemented in hardware or firmware due to its fixed packet format. Thus, the use of BFD for detecting MPLS LSP data plane faults has the following advantages:
a) Support for fault detection for greater number of LSPs.
  • b) Fast detection. Detection with sub-second granularity is
    considered as fast detection. LSP Ping is intended to be used in an environment where fault detection messages are exchanged, either for diagnostic purposes or for infrequent periodic fault detection, in the order of tens of seconds or minutes. Hence, it is not appropriate for fast detection. BFD, on the other hand, is designed for sub-second fault detection intervals. Following are some potential cases when fast detection may be desirable for MPLS LSPs:
    1. In the case of a bypass LSP used for a facility-based link or node protection . In this case, the bypass LSP is essentially being used as an alternate link to protect one or more LSPs. It represents an aggregate and is used to carry data traffic belonging to one or more LSPs, when the link or the node being protected fails. Hence, fast failure detection of the bypass LSP may be desirable particularly in the event of link or node failure when the data traffic is moved to the bypass LSP.
    2. MPLS Pseudowires (PWs). Fast detection may be desired for MPLS PWs depending on i) the model used to layer the MPLS network with the Layer 2 network, and ii) the service that 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 provide 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 that the MPLS PW is emulating, fast failure detection may be desirable.
There may be other potential cases where fast failure detection is desired for MPLS LSPs.
Using BFD in Conjunction with LSP Ping BFD can be used for MPLS LSP data plane fault detection. However, it does not have all the functionality of LSP Ping. In particular, it cannot be used for verifying the control plane against the data plane. LSP Ping performs the following functions that are outside the scope of BFD:
  • a) Association of an LSP Ping Echo request message with a FEC. In
    the case of Penultimate Hop Popping (PHP) or when the egress Label Switching Router (LSR) distributes an explicit null label to the penultimate hop router, for a single label stack LSP, the only way to associate a fault detection message with a FEC is by carrying the FEC in the message. LSP Ping provides this functionality. Next-hop label allocation also makes it necessary to carry the FEC in the fault detection message as the label alone is not sufficient to identify the LSP being verified. In addition, presence of 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.
Hence, BFD is used in conjunction with LSP Ping for MPLS LSP fault detection:
  • i) LSP Ping is used for bootstrapping 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 ensuring that the LSP is mapped to the same FEC, at the egress, as the ingress.
Theory of Operation 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 are processed by the BFD processing module of the egress LSR. If the LSP is associated with multiple FECs, a BFD session SHOULD be established for each FEC. For instance, this may happen in the case of next-hop label allocation. Hence, the operation is conceptually similar to the data plane fault detection procedures of LSP Ping. If MPLS fast-reroute is being used for the MPLS LSP, the use of BFD for fault detection can result in false fault detections if the BFD fault detection interval is less than the MPLS fast-reroute switchover time. When MPLS fast-reroute is triggered because of a link or node failure, BFD Control packets will be dropped until traffic is switched on to the backup LSP. If the time taken to perform the switchover exceeds the BFD fault detection interval, a fault will be 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 determine each of these alternate paths. A BFD session SHOULD be established for each alternate path that is 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 to periodically verify the control plane against the data plane by ensuring that the LSP is mapped to the same FEC, at the egress, as the ingress. The rate of generation of these LSP Ping Echo request messages SHOULD be significantly less than the rate of generation of the BFD Control packets. An implementation MAY provide configuration options to control the rate of generation of the periodic LSP Ping Echo request messages. To enable fault detection procedures specified in this document, for a particular MPLS LSP, this document requires the ingress and egress LSRs to be configured. This includes configuration for supporting BFD and LSP Ping as specified in this document. It also includes configuration that enables the ingress LSR to determine the method used by the egress LSR to identify Operations, Administration, and Maintenance (OAM) packets, e.g., whether the Time to Live (TTL) of the innermost MPLS label needs to be set to 1 to enable the egress LSR to identify the OAM packet. For fault detection for MPLS PWs, this document assumes that the PW control channel type is configured and the support of LSP Ping is also configured.
Initialization and Demultiplexing A BFD session may be established for a FEC associated with an MPLS LSP. As described above, in the case of PHP or when the egress LSR distributes an explicit null label to the penultimate hop router, or next-hop label allocation, the BFD Control packet received by the egress LSR does not contain sufficient information to associate it with a BFD session. Hence, the demultiplexing MUST be done using the remote discriminator field in the received BFD Control packet. The exchange of BFD discriminators for this purpose is described in the next section.
Session Establishment A BFD session is bootstrapped using LSP Ping. This specification describes procedures only for BFD asynchronous mode. BFD demand mode is outside the scope of this specification. Further, the use of the BFD Echo function is outside the scope of this specification. The initiation of fault detection for a particular <MPLS LSP, FEC> combination results in the exchange of LSP Ping Echo request and Echo reply packets, in the 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 assigned by the ingress LSR for the BFD session. This MUST subsequently be used as the My Discriminator field in the BFD session packets sent by the ingress LSR. On receipt of the LSP Ping Echo request message, the egress LSR MUST send a BFD Control packet to the ingress LSR, if the validation of the FEC in the LSP Ping Echo request message succeeds. This BFD Control packet MUST set the Your Discriminator field to the discriminator received from the ingress LSR in the LSP Ping Echo request message. The local discriminator assigned by the egress LSR MUST be used as the My Discriminator field in the BFD session packets sent by the egress LSR. The ingress LSR follows the procedures in 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 demultiplexes the BFD session based on the received Your Discriminator field. 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 this to demultiplex the BFD session. The egress LSR processes the LSP Ping Echo request message in accordance with the procedures defined in [RFC 8029]. The LSP Ping Echo reply message generated by the egress LSR MAY carry the local discriminator assigned by it for the BFD session, as specified in section 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.
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 to enable the egress LSR's control plane to receive the packet . For MPLS PWs, alternatively, the presence of a fault detection message may be indicated by setting a bit in the control word . The BFD Control packet sent by the ingress LSR MUST be a UDP packet with a well-known destination port 3784 and a source port assigned by the sender as per the procedures in . 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:0/104 range for IPv6 with the following 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 this case, the destination IP address, used in a BFD session established for one such alternate path, is the address in the 127/8 range for IPv4 or 0:0:0:0:0:FFFF:7F00:0/104 range for IPv6 discovered by LSP Ping traceroute to exercise that particular alternate path. The motivation for using the address range 127/8 is the same as specified in Section 2.1 of . This is an exception to the behavior defined in . The IP TTL or hop limit MUST be set to 1 . 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 . If this is the case, the destination IP address MUST be set to the source IP address of the LSP Ping Echo request message, received by the egress LSR 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 the fault detection is being performed corresponds to a bidirectional LSP or an MPLS PW. This 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:0/104 range for IPv6. The BFD Control packet sent by the egress LSR MUST have a well-known destination port 4784, if it is routed , or it MUST have a well-known destination port 3784 if it is encapsulated in a MPLS label stack. The source port MUST be assigned by the egress LSR as per the procedures in [BFD-IP]. Note that 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 implies that 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 if the My Discriminator or the Source IP address fields of the received packet do not match the values associated with the session.
Procedures for multiple BFD over MPLS sessions
Section 4 of specifies the procedure for bootstrapping BFD sessions using LSP ping. It further states that "a BFD session SHOULD be established for each alternate path that is discovered". This requirement has been the source of some ambiguity as the procedures of establishing concurrent, multiple sessions have not been explicitly specified. This ambiguity can also be attributed in part to the text in Section 7 of forbidding either end to change local discriminator values in BFD control packets after the session reaches the UP state. The following procedures are described to clarify the ambiguity based on the interpretation of the authors's reading of the referenced sections: At the ingress LSR:
  • MPLS LSP ping can be used to bootstrap multiple BFD sessions for a given <MPLS FEC, LSP>. Each LSP ping MUST carry a different discriminator value in the BFD discriminator TLV .
The egress LSR needs to perform the following:
  • If the validation of the FEC in the MPLS Echo request message succeeds, check the discriminator specified in the BFD discriminator TLV of the MPLS Echo request. If there is no local session that corresponds to the (remote) discriminator received in the MPLS Echo request, a new session is bootstrapped and a local discriminator is allocated. The validation of a FEC is a necessary condition to be satisfied to create a new BFD session at the egress LSR. However, the policy or procedure if any, to be applied by the egress LSR before allowing a new BFD session to be created is outside the scope of this document. Such policies or procedures could consider availability of system resources before allowing a session to be created. When the egress LSR disallows the creation of a BFD session due to policy, it MUST drop the MPLS Echo request message.
  • Ensure the uniqueness of the <MPLS FEC, LSP, Remote Discriminiator> tuple.
  • Except for the clarification mentioned above, the remaining procedures of BFD session establishment are as specified in Sections 4-6 of .
Both the ingress LSR and egress LSR use the YourDiscriminator of the received BFD packet to demultiplex BFD sessions.
does not specify an explicit procedure for deleting BFD sessions. The procedure for removing a BFD session established by an out-of-band discriminator exchange using the MPLS LSP ping can improve resource management (like memory etc.) especially in scenarios involving thousands or more of such sessions. A few observations are made here:
  • The BFD session MAY be removed in the egress LSR if the BFD session transitions from UP to DOWN. This can either be done immediately after the BFD session transitions from UP to DOWN or after the expiry of a configurable timer started after the BFD session state transitions from UP to DOWN at the egress LSR to reduce flapping by adding hysteresis.
  • The BFD session on the egress LSR MAY be removed by the ingress LSR by using the BFD diagnostic code AdminDown(7) as specified in . When the ingress LSR wants to remove a session without triggering any state change at the egress, it MAY transmit BFD packets indicating the State as Down(1), diagnostic code AdminDown(7) detectMultiplier number of times. Upon receiving such a packet, the egress LSR MAY remove the BFD session, without triggering a change of state.
  • The procedures to be followed at the egress LSR when BFD session(s) remain in the DOWN state for a significant amount of time is a local matter. Such procedures are outside the scope of this document.
  • All BFD sessions established with the FEC MUST be removed automatically if the FEC is removed.
  • The egress MUST use the discriminators exchanged when the session was brought UP, to indicate any session state change to the ingress. The egress SHOULD reset this to zero after transmitting bfd.detectMult number of packets if the BFD session transitions to DOWN state.
The discriminators of a BFD session established over an MPLS LSP cannot be changed when it is in UP state. The BFD session could be removed after a graceful transition to AdminDown state using the BFD diagnostic code AdminDown. A new session could be established with a different discriminator. The initiation of the transition from the Up to Down state can be done either by the ingress LSR or the egress LSR.
Backwards Compatibility The procedures clarified by this document are fully backward compatible with an existing implementation of . While the capability to bootstrap and maintain multiple BFD sessions may not be present in current implementations, the procedures outlined by this document can be implemented as a software upgrade without affecting existing sessions. In particular, the egress LSR needs to support multiple BFD sessions per <MPLS FEC, LSP> before the ingress LSR is upgraded.
Security Considerations Security considerations discussed in , , and apply to this document. For BFD Control packets sent by the ingress LSR or when the BFD Control packet sent by the egress LSR are encapsulated in an MPLS label stack, MPLS security considerations apply. These are discussed in . When BFD Control packets sent by the egress LSR are routed, the authentication considerations discussed in should be followed. It is highly important to ensure only minimum number of BFD sessions are provisioned per FEC, and bootstrapped BFD sessions are properly deleted when no longer required. Additionally security measures described in and are to be followed.
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.
Acknowledgments TBD
References Normative References Informative References Layer 2 VPNs Over Tunnels 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
Implementation Status Note to the RFC Editor: This section may be removed upon publication as an RFC. This section documents the implementation status of this document. is built as an application of the BFD protocol in , hence the coverage discusses applicable sections of the BFD protocol to the MPLS transport. For e.g. sections related to BFD Echo functionality and Demand mode are skipped.
  • The organization responsible for the implementation, if any.
  • The implementation's name and/or a link to a web page where the implementation or a description of it can be found.
  • A brief general description.
  • The implementation's level of maturity: research, prototype, alpha, beta, production, widely used, etc.
  • Coverage: which parts of the protocol specification are implemented.
  • Version compatibility: what version/versions of the Internet-Draft are known to be implemented.
  • Licensing: the terms under which the implementation can be used. For example: proprietary, royalty licensing, freely distributable with acknowledgement (BSD style), freely distributable with requirement to redistribute source (General Public License (GPL) style), and other (specify).
  • Implementation experience: any useful information the implementers want to share with the community.
  • Contact information: ideally a person's name and email address, but possibly just a URL or mailing list.
  • The date when information about this particular implementation was last updated.
Organization:
TBF
Implementation Name:
TBF
Description:
BFD over MPLS feature
Maturity:
TBF
Coverage:
  • Section x.
  • RFC5884 - 3.2: Bootstrapping BFD over LSP using LSP ping
  • RFC5884 - 3.2: Setting BFD fault detection parameters for the LSP
  • RFC5884 - 4.0: Periodic LSP Ping echo request messages
  • RFC5884 - 4.0: Configuration knobs for enablement and operation of BFD and LSP ping
  • RFC5884 - 5.0: Demultiplexing logic for BFD sessions based on remote Discriminator
  • RFC5884 - 6.0: LSP Ping Echo request message with local discriminator for session establishment using BFD Discriminator TLV (Sec 6.1)
  • RFC5884 - 6.0: Egress LSR validates FEC and follows procedures for discriminators
  • RFC5884 - 7.0: Dataplane formats for BFD over MPLS using TTL=1.
  • RFC5880 - 6.3: unique discriminator per session
  • RFC5880 6.5: Poll Sequence
  • RFC5880 6.7: Authentication
  • RFC5880 6.7.2: Simple Password Authentication
  • RFC5880 6.7.3: Keyed MD5 and Meticulous Keyed MD5 Authentication
  • RFC5880 6.7.4: Keyed SHA1 and Meticulous Keyed SHA1 Authentication
  • RFC5880 6.8.1: State Variables
  • RFC5880 6.8.2: Timer Negotiation
  • RFC5880 6.8.3: Timer Manipulation
  • RFC5880 6.8.4: Detection Time Calculation
  • RFC5880 6.8.6: Reception of BFD Control Packets
  • RFC5880 6.8.7: Transmitting BFD Control Packets
  • RFC5880 6.8.10: Min Rx Interval Change
  • RFC5880 6.8.11: Min Tx Interval Change
  • RFC5880 6.8.12: Detect Multiplier Change
  • RFC5880 6.8.15: Forwarding Plane Reset
  • RFC5880 6.8.16: Administrative Control
  • RFC5880 6.8.17: Concatenated Paths
  • RFC5880 6.8.18: Session Hold Down
  • RFC5880 9: Generalized TTL Security Mechanism
Version Compatibility:
TBF
Licensing:
TBF
Implementation Experience:
Contact Information:
TBF
Last Updated:
TBF