Network Working Group R. Aggarwal
Internet Draft Juniper Networks
Expiration Date: September 2007
K. Kompella
Juniper Networks
T. Nadeau
Cisco Systems, Inc.
G. Swallow
Cisco Systems, Inc.
March 2007
BFD For MPLS LSPs
draft-ietf-bfd-mpls-04.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Raggarwa [Page 1]
Internet Draft draft-ietf-bfd-mpls-04.txt March 2007
Abstract
One desirable application of Bi-directional Forwarding Detection
(BFD) is to detect a MPLS 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.
Table of Contents
1 Specification of requirements ......................... 3
2 Introduction .......................................... 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 ................................... 5
5 Initialization and Demultiplexing ..................... 6
6 Session Establishment ................................. 7
6.1 BFD Discriminator TLV in LSP-Ping ..................... 7
7 Encapsulation ......................................... 8
8 Security Considerations ............................... 9
9 IANA Considerations ................................... 9
10 Acknowledgments ....................................... 9
11 References ............................................ 9
11.1 Normative References .................................. 9
11.2 Informative References ................................ 10
12 Author Information .................................... 10
13 Intellectual Property Statement ....................... 11
14 Full Copyright Statement .............................. 12
Raggarwa [Page 2]
Internet Draft draft-ietf-bfd-mpls-04.txt March 2007
1. 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].
2. Introduction
One desirable application of Bi-directional Forwarding Detection
(BFD) is to track the liveliness of a Multi Protocol Label Switched
(MPLS) Label Switched Path (LSP). In particular BFD can be used to
detect a data plane failure in the forwarding path of a MPLS LSP.
LSP-Ping [RFC4379] 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.
3. Applicability
In the event of a 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 [RFC4377].
3.1. BFD for MPLS LSPs: Motivation
LSP-Ping described in [LSP-Ping] is an existing mechanism for
detecting a 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 a MPLS LSP. The LSP may be associated with
any of the following FECs:
a) RSVP IPv4/IPv6 Session [RFC3209]
b) LDP IPv4/IPv6 prefix [RFC3036]
c) VPN IPv4/IPv6 prefix [RFC4364]
d) Layer 2 VPN [L2-VPN]
Raggarwa [Page 3]
Internet Draft draft-ietf-bfd-mpls-04.txt March 2007
e) Layer 2 Circuit ID [RFC4447]
LSP-Ping includes extensive control plane verification. BFD on the
other hand was designed as a light-weight 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 its 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 facility based link or
node protection [RFC4090]. 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 Pseudo Wires (PW). 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. Use of BFD
for PWs is further described in [VCCV] and [OAM-MAP].
There may be other potential cases where fast failure detection is
desired for MPLS LSPs.
Raggarwa [Page 4]
Internet Draft draft-ietf-bfd-mpls-04.txt March 2007
3.2. 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 funcitonality of LSP-Ping. In paticular 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 a LSP-Ping echo request message with a FEC. In
the case of Penultimate Hop Popping (PHP), 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 to
this presence of the FEC in the echo request message makes is
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 boot-strapping 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.
4. Theory of Operation
To use BFD for fault detection on a 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 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
Raggarwa [Page 5]
Internet Draft draft-ietf-bfd-mpls-04.txt March 2007
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 a 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 implemetation MAY provide configuration
options to control the rate of generation of the periodic LSP-Ping
echo request messages.
5. Initialization and Demultiplexing
A BFD session may be established for a FEC associated with a MPLS
LSP. As desribed above in the case of PHP and 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.
Raggarwa [Page 6]
Internet Draft draft-ietf-bfd-mpls-04.txt March 2007
6. Session Establishment
A BFD session is boot-strapped using LSP-Ping. This specification
describes procedures only for BFD asynchronous mode. 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 a 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. 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 egress LSR MAY respond with a LSP-Ping echo reply message that
carries the local discriminator assigned by it 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 sent by the
egress LSR.
Once the ingress LSR learns the local discriminator assigned by the
egress LSR for a given BFD session, it MUST send a BFD control packet
to the egress LSR with the Your Discriminator set to the local
discriminator of the egress LSR. 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.
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 is requested to assign 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.
Raggarwa [Page 7]
Internet Draft draft-ietf-bfd-mpls-04.txt March 2007
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 to enable the egress LSR's control
plane to receive the packet [LSP-Ping]. For MPLS PWs, alternatively,
the presence of a fault detection message may be indicated by setting
a bit in the control word [VCCV].
The BFD control packet sent by the ingress LSR MUST be a UDP packet
with a well known destination port 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 is randomly chosen from the 127/8 range, with the following
exception. If the FEC is a 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 discovered by LSP-ping traceroute [RFC4379] to
exercise that particular alternate path.
The IP TTL 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 source
port is the well-known UDP port 3784. The destination IP address and
UDP port MUST be copied from the source IP address and UDP port of
the control packet received from the ingress LSR.
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]. Or the BFD control packet sent by the egress LSR to
the ingress LSR MAY be encapsulated in a MPLS label stack. If this is
the 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 perfomed corresponds to a bi-directional LSP or a
MPLS PW. This may also be the case when there is a return LSP from
the egress LSR to the ingress LSR.
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 a LSR MUST ignore
BFD packets for a given session, that is 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
Raggarwa [Page 8]
Internet Draft draft-ietf-bfd-mpls-04.txt March 2007
received packet do not match the values associated with the session.
8. Security Considerations
Security considerations discussed in [BFD], [BFD-MHOP] and [LSP-Ping]
apply to this document.
9. IANA Considerations
This document introduces a BFD discriminator TLV in LSP-Ping. This
has to be assigned from the TLV type registry maintained by IANA.
IANA is requested to assign a value of 15 to this TLV.
10. Acknowledgments
We would like to thank 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.
11. References
11.1. Normative References
[BFD] Katz, D., and Ward, D., "Bidirectional Forwarding
Detection",
draft-ietf-bfd-base-06.txt.
[BFD-IP] D. Katz, D. Ward, "BFD for IPv4 and IPv6 (Single Hop)",
draft-ietf-bfd-v4v6-1hop-05.txt
[RFC4379] K. Kompella et. al., "Detecting MPLS Data Plane Failures",
RFC 4379, February 2006.
[RFC] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Raggarwa [Page 9]
Internet Draft draft-ietf-bfd-mpls-04.txt March 2007
11.2. Informative References
[BFD-MHOP] D. katz, D. Ward, "BFD for Multihop Paths",
draft-ietf-bfd-multihop-04.txt
[VCCV] T. Nadeau, C. Pignataro, R. Aggarwal,
"Pseudo Wire (PW) Virtual Circuit Connection Verification
((VCCV)",
draft-ietf-pwe3-vccv-13.txt
[RFC3209] Awduche, D., et. al, "RSVP-TE: Extensions to RSVP for LSP
tunnels", RFC 3209, December 2001.
[RFC4090] P. Pan, et. al., "Fast Reroute Extensions to RSVP-TE for
LSP Tunnels", May 2005.
[RFC3036] Andersson, L., et al, "LDP Specification", RFC 3036.
[RFC4364] E. Rosen, Y. Rekhter, "BGP/MPLS IP VPNs", RFC 4364,
February 2006.
[L2-VPN] K. Kompella, et. al., "Layer 2 VPNs Over Tunnels",
draft-kompella-ppvpn-l2vpn-03.txt
[RFC4447] L. Martini et. al.,"Pseudowire Setup and Maintenance
using LDP", RFC 4447, April 2006.
[OAM-MAP] Nadeau, T., Morrow, M., Busschbach, P., et. al,
Pseudo Wire (PW) OAM Message Mapping,
draft-ietf-pwe3-oam-msg-map-02.txt, January 2004
[RFC4377] Nadeau, T., et. al, "OAM Requirements for MPLS
Networks", RFC 4377, February 2006.
12. Author Information
Rahul Aggarwal
Juniper Networks
1194 North Mathilda Ave.
Sunnyvale, CA 94089
Email: rahul@juniper.net
Kireeti Kompella
Juniper Networks
1194 North Mathilda Ave.
Sunnyvale, CA 94089
Email: kireeti@juniper.net
Raggarwa [Page 10]
Internet Draft draft-ietf-bfd-mpls-04.txt March 2007
Thomas D. Nadeau
Cisco Systems, Inc.
300 Beaver Brook Road
Boxboro, MA 01719
Phone: +1-978-936-1470
Email: tnadeau@cisco.com
George Swallow
Cisco Systems, Inc.
300 Beaver Brook Road
Boxborough , MA - 01719
USA
Email: swallow@cisco.com
13. Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Raggarwa [Page 11]
Internet Draft draft-ietf-bfd-mpls-04.txt March 2007
14. Full Copyright Statement
Copyright (C) The IETF Trust (2007). This document is subject to the
rights, licenses and restrictions contained in BCP 78, and except as
set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE,
Raggarwa [Page 12]
