[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: 00 01 02 03 04 05 06 07 RFC 5884

Network Working Group                                        R. Aggarwal
Internet Draft                                          Juniper Networks
Expiration Date: January 2006
                                                             K. Kompella
                                                        Juniper Networks

                                                               T. Nadeau
                                                     Cisco Systems, Inc.

                                                              G. Swallow
                                                     Cisco Systems, Inc.

                                                               July 2005


                           BFD For MPLS LSPs


                       draft-ietf-bfd-mpls-02.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, et al.                                                [Page 1]

Internet Draft         draft-ietf-bfd-mpls-02.txt              July 2005


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  .................................   6
 6.1        BFD Discriminator TLV in LSP-Ping  .....................   7
 7          Encapsulation  .........................................   7
 8          Security Considerations  ...............................   8
 9          IANA Considerations  ...................................   8
10          Acknowledgments  .......................................   8
11          References  ............................................   8
11.1        Normative References  ..................................   8
11.2        Informative References  ................................   8
12          Author Information  ....................................   9
13          Intellectual Property Statement  .......................  10
14          Full Copyright Statement  ..............................  10










Raggarwa, et al.                                                [Page 2]

Internet Draft         draft-ietf-bfd-mpls-02.txt              July 2005


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 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 for-
   warding path of a MPLS LSP. LSP-Ping [LSP-PING] is an existing mecha-
   nism 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.


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 func-
   tional 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].


3.1. BFD for MPLS LSPs: Motivation

   LSP-Ping described in [LSP-Ping] is an existing mechanism for detect-
   ing 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]




Raggarwa, et al.                                                [Page 3]

Internet Draft         draft-ietf-bfd-mpls-02.txt              July 2005


   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 consid-
   ered as fast detection. LSP-Ping is intended to be used in an envi-
   ronment 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. Fol-
   lowing 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 rep-
   resents 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 par-
   ticularly 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.











Raggarwa, et al.                                                [Page 4]

Internet Draft         draft-ietf-bfd-mpls-02.txt              July 2005


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 can-
   not 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 func-
   tionality. Next-hop label allocation also makes it necessary to carry
   the FEC in the fault detection message as the label alone is not suf-
   ficient to identify the LSP being verified. In addition to this pres-
   ence of the FEC in the echo request message makes is possible to ver-
   ify the control plane against the data plane at the egress LSR.

     b) ECMP considerations. LSP-Ping makes it possible to exercise mul-
   tiple 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) pack-
   ets 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 map-
   pings.


4. Theory of Operation

   To use BFD for fault detection on a MPLS LSP a BFD session is estab-
   lished 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.



Raggarwa, et al.                                                [Page 5]

Internet Draft         draft-ietf-bfd-mpls-02.txt              July 2005


   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 traf-
   fic 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.


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 alloca-
   tion the BFD control packet received by the egress LSR does not con-
   tain 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 dis-
   criminators for this purpose is described in the next section.


6. 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 for that <MPLS
   LSP, FEC>. 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 discrimina-
   tor 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 discrimi-
   nator 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.





Raggarwa, et al.                                                [Page 6]

Internet Draft         draft-ietf-bfd-mpls-02.txt              July 2005


6.1. BFD Discriminator TLV in LSP-Ping

   LSP-Ping echo request and echo reply messages carry a BFD discrimina-
   tor 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.


7. Encapsulation

   BFD control packets sent by the ingress LSR are encapsulated in the
   MPLS label stack that corresponds to the FEC for which fault detec-
   tion 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 nec-
   essary for certain FECs to enable the egress LSR's control plane to
   receive the packet [LSP-Ping]. For MPLS PWs, alternatively, the pres-
   ence 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
   routed based on the destination IP address [BFD-MHOP].

   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
   received packet do not match the values associated with the session.



Raggarwa, et al.                                                [Page 7]

Internet Draft         draft-ietf-bfd-mpls-02.txt              July 2005


8. Security Considerations

   Security considerations discussed in [BFD] 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 docu-
   ment 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-03.txt.

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

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


11.2. Informative References

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

   [BFD-MHOP] D. katz, D. Ward, "BFD for Multihop Paths",
              draft-ietf-bfd-multihop-03.txt

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




Raggarwa, et al.                                                [Page 8]

Internet Draft         draft-ietf-bfd-mpls-02.txt              July 2005


   [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-ietf-pwe3-oam-msg-map-02.txt, January 2004

   [OAM-REQ]  Nadeau, T., et. al, "OAM Requirements for MPLS
              Networks", draft-ietf-mpls-oam-requirements-02.txt,
              June 2003.


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

   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



Raggarwa, et al.                                                [Page 9]

Internet Draft         draft-ietf-bfd-mpls-02.txt              July 2005


   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 assur-
   ances 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.



14. Full Copyright Statement

   Copyright (C) The Internet Society (2005).  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 AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFOR-
   MATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
   OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.






Raggarwa, et al.                                               [Page 10]

Internet Draft         draft-ietf-bfd-mpls-02.txt              July 2005





















































Raggarwa, et al.                                               [Page 11]


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