[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

Network Working Group                                  Rahul Aggarwal
Internet Draft                                         Kireeti Kompella
Expiration Date: April 2004                            Juniper Networks


                           BFD For MPLS LSPs

                     draft-raggarwa-mpls-bfd-00.txt


Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   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 BFD is to detect a MPLS LSP data plane
   failure.  LSP-Ping [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 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.







draft-raggarwa-mpls-bfd-00.txt                                  [Page 1]


Internet Draft       draft-raggarwa-mpls-bfd-00.txt         October 2003


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 user traffic, it may
   not always be possible to detect the failure using the MPLS control
   plane. Hence there is a need for a mechanism to detect a data plane
   failure in the MPLS LSP path.

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]
     d) Layer 2 VPN [L2-VPN]
     e) Layer 2 Circuit ID [LDP-PW]

   LSP-Ping is a more computationally expensive mechanism than BFD for
   detecting MPLS LSP data plane faults. The control plane processing



draft-raggarwa-mpls-bfd-00.txt                                  [Page 2]


Internet Draft       draft-raggarwa-mpls-bfd-00.txt         October 2003


   required at the egress/ingress LSRs for processing LSP-Ping echo
   request/reply messages is greater than the processing required for
   BFD control packets. 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. Since
   BFD is a more lightweight mechanism than LSP-Ping it may be possible
   to provide data plane fault detection for a 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 node
   protection [LSP-FR]. In this case the bypass LSP is essentially being
   used as an alternate link. It represents an aggregate and is used to
   carry a set of other LSPs. Hence fast failure detection of the bypass
   LSP may be desirable.

      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

   We would like to point that the applicability of fast detection to
   MPLS LSPs needs more study and operational input.

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



draft-raggarwa-mpls-bfd-00.txt                                  [Page 3]


Internet Draft       draft-raggarwa-mpls-bfd-00.txt         October 2003


   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.


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.














draft-raggarwa-mpls-bfd-00.txt                                  [Page 4]


Internet Draft       draft-raggarwa-mpls-bfd-00.txt         October 2003


4. Initialization and Demultiplexing

   A BFD session is established for each 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 <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. 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 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.










draft-raggarwa-mpls-bfd-00.txt                                  [Page 5]


Internet Draft       draft-raggarwa-mpls-bfd-00.txt         October 2003


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 IP TTL is set to
   255. The BFD control packet sent by the egress LSR to the ingress is
   routed based on the destination IP address.


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.















draft-raggarwa-mpls-bfd-00.txt                                  [Page 6]


Internet Draft       draft-raggarwa-mpls-bfd-00.txt         October 2003


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.  Thanks also to Yakov Rekhter for his comments on this
   document.


10. Normative References

      [BFD]      Katz, D., and Ward, D., "Bidirectional Forwarding Detection",
                 draft-katz-ward-bfd-01.txt, August 2003.

      [LSP-Ping] K. Kompella et. al., "Detecting MPLS Data Plane Failures",
                 draft-ietf-mpls-lsp-ping-03.txt

      [RFC]      Bradner, S., "Key words for use in RFCs to Indicate
                 Requirement Levels", BCP 14, RFC 2119, March 1997.

      [VCCV]     T. Nadeau, R. Aggarwal, "Pseudo Wire (PW) Virtual Circuit
                 Connection Verification ((VCCV)",
                 draft-ietf-pwe3-vccv-00.txt


      [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, January

      [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-03.txt


   Informative References


      [BFD-IP]  D. Katz, D. Ward, "BFD for IPv4 and IPv6 (Single Hop)",
                draft-katz-ward-bfd-v4v6-1hop-00.txt






draft-raggarwa-mpls-bfd-00.txt                                  [Page 7]


Internet Draft       draft-raggarwa-mpls-bfd-00.txt         October 2003


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



IPR Notice

   The IETF takes no position regarding the validity or scope of any
   intellectual property 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; neither does it represent that it
   has made any effort to identify any such rights.  Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11.  Copies of
   claims of rights made available for publication 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 implementors or users of this specification can
   be obtained from the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard.  Please address the information to the IETF Executive
   Director.













draft-raggarwa-mpls-bfd-00.txt                                  [Page 8]


Internet Draft       draft-raggarwa-mpls-bfd-00.txt         October 2003


Full Copyright Notice

   Copyright (C) The Internet Society (2003).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   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."


Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.


















draft-raggarwa-mpls-bfd-00.txt                                  [Page 9]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/