Network Working Group Rahul Aggarwal Internet Draft Kireeti Kompella Expiration Date: January 2005 Juniper Networks Thomas D. Nadeau George Swallow Cisco Systems, Inc BFD For MPLS LSPs draft-ietf-bfd-mpls-00.txt Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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. 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 draft-ietf-bfd-mpls-00.txt [Page 1] Internet Draft draft-ietf-bfd-mpls-00.txt July 2004 applicability of BFD in relation to LSP-Ping for this application. It also describes procedures for using BFD in this environment. Conventions used in this document 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 RFC-2119 [KEYWORDS]. 1. Introduction One desirable application of 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 [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 in this environment. 2. 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 [OAM-REQ]. 2.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) 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 [RSVP-TE] b) LDP IPv4/IPv6 prefix [LDP] c) VPN IPv4/IPv6 prefix [2547] draft-ietf-bfd-mpls-00.txt [Page 2] Internet Draft draft-ietf-bfd-mpls-00.txt July 2004 d) Layer 2 VPN [L2-VPN] e) Layer 2 Circuit ID [LDP-PW] 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 in the order of seconds. 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 [LSP-FR]. 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]. We would like to point that the applicability of fast detection to MPLS LSPs needs more study and operational input. draft-ietf-bfd-mpls-00.txt [Page 3] Internet Draft draft-ietf-bfd-mpls-00.txt July 2004 2.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) ECMP considerations. LSP-Ping makes it possible to exercise multiple alternate paths for a given LSP. 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 re-synchronizing the MPLS LSP and FEC mappings. draft-ietf-bfd-mpls-00.txt [Page 4] Internet Draft draft-ietf-bfd-mpls-00.txt July 2004 3. Theory of Operation To use BFD for fault detection on a MPLS LSP a BFD session is established for that particular MPLS LSP. BFD control packets are sent along the same data path as the LSP being verified and are processed by the control plane of the egress LSR. If the LSP is associated with multiple FECs, a BFD session is 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 make the switchover exceeds the BFD fault detection interval a fault will be delcared 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. 4. 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 has to 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. 5. Session Establishment A BFD session is boot-strapped using LSP-Ping. The initiation of fault detection for a particular 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 . To establish a BFD session a LSP-Ping echo request message carries the local discriminator assigned by the ingress LSR for the BFD session. This is subsequently used as the My Discriminator field in the BFD session packets sent by the ingress LSR. The egress LSR responds with a echo reply message that carries the local discriminator assigned by it for the BFD session. This is subsequently used as the My Discriminator field in the BFD session draft-ietf-bfd-mpls-00.txt [Page 5] Internet Draft draft-ietf-bfd-mpls-00.txt July 2004 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 sends 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. It sends control packets to the ingress LSR with the Your Discriminator field set to the local discriminator of the ingress LSR. The ingress LSR can use this to demultiplex the BFD session. 5.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. This TLV has a type TBD and 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. 6. Encapsulation BFD control packets sent by the ingress LSR are 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 maybe 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 TBD and a source port assigned by the sender. The source IP address is a routable address of the sender. The destination IP address is a (randomly chosen) address from 127/8. The IP TTL is 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 TBD. The destination IP address and UDP port are 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 encapsulated in a MPLS label stack and 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. It may also be draft-ietf-bfd-mpls-00.txt [Page 6] Internet Draft draft-ietf-bfd-mpls-00.txt July 2004 routed based on the destination IP address [BFD-MHOP]. 7. Security Considerations Security considerations discussed in [BFD] and [LSP-Ping] apply to this document. 8. 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. 9. 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. 10. References 10.1. Normative References [BFD] Katz, D., and Ward, D., "Bidirectional Forwarding Detection", draft-katz-ward-bfd-02.txt, August 2003. [LSP-Ping] K. Kompella et. al., "Detecting MPLS Data Plane Failures", draft-ietf-mpls-lsp-ping-05.txt [RFC] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 10.2. Informative References [BFD-IP] D. Katz, D. Ward, "BFD for IPv4 and IPv6 (Single Hop)", draft-katz-ward-bfd-v4v6-1hop-01.txt [BFD-MHOP] D. katz, D. Ward, "BFD for Multihop Paths", draft-ietf-bfd-multihop-00.txt [VCCV] T. Nadeau, R. Aggarwal, "Pseudo Wire (PW) Virtual Circuit Connection Verification ((VCCV)", draft-ietf-pwe3-vccv-03.txt draft-ietf-bfd-mpls-00.txt [Page 7] Internet Draft draft-ietf-bfd-mpls-00.txt July 2004 [RSVP-TE] Awduche, D., et al, "RSVP-TE: Extensions to RSVP for LSP tunnels", RFC 3209, December 2001. [LDP] Andersson, L., et al, "LDP Specification", RFC 3036. [2547] E. Rosen, Y. Rekhter, "BGP/MPLS IP VPNs", draft-ietf-l3vpn-rfc2547bis-01.txt [L2-VPN] K. Kompella, et. al., "Layer 2 VPNs Over Tunnels", draft-kompella-ppvpn-l2vpn-03.txt [LDP-PW] L. Martini et. al.,"Pseudowire Setup and Maintenance using LDP", draft-ietf-pwe3-control-protocol-08.txt [OAM-MAP] Nadeau, T., Morrow, M., Busschbach, P., et. al, Pseudo Wire (PW) OAM Message Mapping, draft-nadeau-pwe3-oam-msg-map-05.txt, January 2004 [OAM-REQ] Nadeau, T., et. al, "OAM Requirements for MPLS Networks", draft-ietf-mpls-oam-requirements-02.txt, June 2003. 11. 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 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. draft-ietf-bfd-mpls-00.txt [Page 8] Internet Draft draft-ietf-bfd-mpls-00.txt July 2004 300 Beaver Brook Road Boxborough , MA - 01719 USA Email: swallow@cisco.com 12. Intellectual Property 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. 13. Full Copyright Statement Copyright (C) The Internet Society (2004). 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 is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. draft-ietf-bfd-mpls-00.txt [Page 9] Internet Draft draft-ietf-bfd-mpls-00.txt July 2004 14. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. draft-ietf-bfd-mpls-00.txt [Page 10]