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

Versions: 00 01 02

Network working group                                         M. Chen
Internet Draft                                                 Huawei
Category: Standards Track                                       N. So
Created: March 5, 2010                                        Verizon
Expires: September 2010                                 V. Hallivuori
                                                              Tellabs





                       BFD for MPLS LSPs Enhancement

                  draft-chen-mpls-bfd-enhancement-01.txt


Abstract

   This document defines an enhancement to Bi-directional Forwarding
   Detection (BFD) for MPLS LSPs [MPLS-BFD] that can be used to specify
   the return path of BFD control packets for a specific BFD session.
   Specifying co-routed or protected return path increases robustness
   of BFD failure detection and reduces false positives. This document
   also defines a way to avoid duplicate BFD sessions currently
   encountered with Co-routed Bidirectional LSP and Associated
   Bidirectional LSP. The enhancement halves the BFD sessions over
   those LSPs, and allows a Co-routed Bidirectional LSPs or Associated
   Bidirectional LSPs to be protected and switched as a single entity.

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with
   the provisions of BCP 78 and 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.






Chen, et al.          Expires September 5, 2010               [Page 1]

Internet-Draft        BFD for MPLS Enhancement              March 2010


   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on August 15, 2009.

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document. Please review these documents
   carefully, as they describe your rights and restrictions with
   respect to this document.

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 [RFC2119].

Table of Contents


   1. Introduction.................................................2
   2. Problem statements...........................................3
   3. Enhancement to BFD for MPLS..................................4
   4. Session Establishment........................................4
      4.1. Session Control TLV.....................................6
      4.2. The usage of IPv4/IPv6 RSVP Tunnel sub-TLVs.............6
   5. Security Considerations......................................7
   6. IANA Considerations..........................................7
      6.1. Return code.............................................8
      6.2. Session Control TLV.....................................8
   7. Acknowledgments..............................................8
   8. References...................................................8
      8.1. Normative References....................................8
      8.2. Informative References..................................9
   Authors' Addresses.............................................10

1. Introduction

   This document defines an enhancement to Bi-directional Forwarding
   Detection (BFD) for MPLS LSPs [MPLS-BFD] that can be used to specify



Chen, et al.          Expires September 5, 2010               [Page 2]

Internet-Draft        BFD for MPLS Enhancement              March 2010


   the return path of BFD control packets for a specific BFD session.
   In traffic engineered networks, LSPs usually do not follow IP
   routing or there are multiple LSPs between same nodes. Specifying
   return path to be congruent with forward path ensures that failures
   in other paths (e.g. shortest path for IP routing) do not cause BFD
   failure detection for the forward path. This extension hence
   increases robustness of BFD based failure detection, especially in
   LSP 1:1 type protection cases. Also specifying FRR protected LSP as
   return path can increase robustness.

   This document also defines a way to avoid duplicate BFD sessions
   when BFD is used for Bidirectional LSP or for a pair of
   unidirectional LSPs. This extension allows a Bidirectional LSP or a
   pair of unidirectional LSPs to be protected and switched as a whole
   entity.

   In this document, term Bidirectional LSP includes Co-routed
   Bidirectional LSP defined in [RFC 3471] [RFC 3473] and Associated
   Bidirectional LSP (that is constructed from a pair of unidirectional
   LSPs).

2. Problem statements

   BFD for MPLS LSPs (BFDoMPLS) is defined in [BFD-MPLS] and used for
   detecting end-to-end reachability of LSP. BFD for MPLS is an
   important feature for the packetized MPLS converged network, as it
   provides end-to-end connectivity verification. Reverse direction of
   MPLS for BFD follows routing, and hence it can not be used for
   protection decisions, if more than one alternate path is available.

   LSP Ping [RFC 4379] is used to bootstrap the BFD sessions. With the
   current mechanisms defined in [BFD-MPLS]:

     1. For each direction of a LSP, a separate BFD session is required
        to be established. The return packets from the terminator of a
        BFD session to the initiator could be either IP or MPLS
        encapsulated, and the choice is of the terminator. That means
        for unidirectional LSP, only one session is needed, but for a
        Bidirectional LSP, there will be two BFD sessions. This will
        result in not only doubling the BFD sessions over the LSP, but
        sometimes failing to perform protection and switching when the
        Bidirectional LSP is desired to be operated as a single entity.
        This is due to the two BFD sessions that are individually
        responsible for each direction of the Bidirectional LSP having
        no inherent relationship.  It is possible that one session
        detects failure and the other does not, with the result that



Chen, et al.          Expires September 5, 2010               [Page 3]

Internet-Draft        BFD for MPLS Enhancement              March 2010


        one direction switches while the other does not. This can cause
        unexpected operational problems.

     2. For a specific BFD session, the return path (which carries the
        BFD control packets), which could be an IP path or a LSP is
        selected by the egress.  The choice is a local decision of the
        egress, and egress does not have enough information to perform
        a choice that would produce both directions of BFD transiting
        same path. In some cases, it is very valuable to specify the
        return path for a BFD session. For example, selecting a more
        reliable return path (e.g., TE LSP with FRR protection) could
        improve the reliability of reply BFD control packets or
        selecting co-routed LSP would allow use of BFDoMPLS as trigger
        for LSP protection.

3. Enhancement to BFD for MPLS

   The enhancement described in this document improves upon "BFD for
   MPLS LSPs" [BFD-MPLS], in the following areas:

     1. Allows LSP ingress node to signal the desired return path for
        any BFDoMPLS session.

     2. Allows operator to provision BFD on both forwarding and return
        path of Bidirectional LSPs with a single BFD session. This
        extension halves the number BFD sessions over the LSP, and
        enables that a Bidirectional LSP could be protected and
        switched as a single entity.

     3. Allows operator to provision BFD on two unidirectional LSPs
        (one for each direction) with a single BFD session. This
        reduces number of BFD sessions, and hence reduces control plane
        load. However in some cases (e.g. where make-before-break is
        used or the operator wants each of the two unidirectional LSPs
        to be operated separately), this is undesirable, and hence this
        feature is optional.

   All the goals listed above are only relevant to BFD session
   establishment, so the enhancement defined in this document is mainly
   focus on BFD session establishment. The "return path specified"
   mechanisms defined in [LSP-PING-RP] are used in this document.

4. Session Establishment

   As defined in [BFD-MPLS], a BFD session is boot-strapped by LSP Ping.
   All the procedures for session establishment defined in [BFD-MPLS]



Chen, et al.          Expires September 5, 2010               [Page 4]

Internet-Draft        BFD for MPLS Enhancement              March 2010


   apply here. In addition to that, a RP TLV defined in [LSP-PING-RP]
   MUST be carried in the echo request. This is used to notify the
   egress LSR to select the return path of the BFD session. The return
   path is identified by the FEC sub-TLV encoded in the RP TLV.

   Except for "Any Candidate sub-TLV" that is defined in [LSP-PING-RP],
   any other sub-TLVs are applicable to be included in RP TLV to
   explicitly specify the return path of a BFD session.

   If RP TLV is present in LSP ping message that setups BFD for MPLS
   sessions:

     o LSP ping reply packet MUST be sent as specified in [LSP-PING-RP].

     o BFD for MPLS packets MUST be sent via same reply channel used
        for LSP ping reply packets.

     o If selected path becomes unavailable (and no other path meeting
        specifications in previously received RP TLV is present),
        transmission of BFD packets MUST be interrupted. Transmission
        of BFD packets MUST resume, if return path LSP becomes
        available.

   It is permissible for multiple BFD for MPLS sessions to use same
   return path -- when node does make-before-break (MBB), it can signal
   separate BFD for MPLS session to test new LSP before taking it into
   use.

   In this document, a new TLV, Session Control TLV is defined. Session
   Control TLV is used to notify the egress LSR whether to establish
   another BFD session for the backward direction of a Bidirectional
   LSP or a pair of unidirectional LSPs (one for each direction). If
   Session Control TLV is carried, the egress LSR MUST not initiate
   another separate BFD session for the backward direction of the
   Bidirectional LSP or the pair of unidirectional LSPs. If BFD session
   has been provisioned to both nodes, the node with a numerically
   larger IP address (comparison using signaled LSP endpoint addresses,
   for example, the terminator could use its own Router ID for
   comparison with the source IP address of the received echo request.)
   shall initiate signaling. The initiator MAY carry an IP address
   (e.g., Router ID) of its own in the Source Address TLV [MPLS-TP-TLV]
   when IP forwarding is disabled (e.g., the scenario of MPLS-TP
   without IP forwarding). If node with the larger IP receives LSP ping
   message signaling BFD session with Session Control TLV, LSP ping
   reply must be transmitted with "Backward direction BFD session
   exists" to the ingress LSR. If there is no Session Control TLV



Chen, et al.          Expires September 5, 2010               [Page 5]

Internet-Draft        BFD for MPLS Enhancement              March 2010


   carried in the echo request, it's up to the egress LSR to decide
   whether to initiate another BFD session for the backward direction
   LSP, this is the same as the definition in [BFD-MPLS].

   When received an echo request with the reply mode set to "Reply via
   specified path" [LSP-PING-RP], if the receiver does not know the
   reply mode, an echo reply with the return code set to "Malformed
   echo request" and the Subcode set to zero SHOULD be send back to the
   initiator. The BFD session will not be established in this case.

   When provisioning a single BFD to a bidirectional LSP or a pair of
   unidirectional LSPs, in case of the forwarding direction of session
   is OK but the reverse direction is not, the initiator MUST not send
   BFD control packets on the session until the echo reply is received
   from the terminator. And the terminator MUST not send BFD control
   packets onto the BFD session until the first BFD control packet is
   received from the initiator.

4.1. Session Control TLV

   Session Control TLV is an optional TLV, it is carried in echo
   request to notify the egress LSR not to initiate another BFD session
   for the backward direction of a Bidirectional LSP or pair of
   unidirectional LSPs (one for each direction). The format of Session
   Control TLV is as follows:

   0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Session Control Type      |          Length               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Session Control TLV Type field is 2 octets in length, and the
   type value is TBD.

   Length field is 2 octets in length, the value of length field SHOULD
   be 0, unless any sub-TLVs (defined in future) are present.

4.2. The usage of IPv4/IPv6 RSVP Tunnel sub-TLVs

   IPv4/IPv6 RSVP Tunnel sub-TLVs are defined in [LSP-PING-RP], which
   are used to notify the egress LSR of a specific LSP how to choose
   the return path for an echo reply.

   In this document, these sub-TLVs are re-used to notify the egress
   LSR of a specific LSP how to choose the return path of a BFD session.


Chen, et al.          Expires September 5, 2010               [Page 6]

Internet-Draft        BFD for MPLS Enhancement              March 2010


   As stated in section 2 of this document, it is possible to have
   multiple parallel LSPs between the ingress and egress LSRs.  In a
   typical network example, a group of parallel LSPs have the same
   tunnel ID but different LSP IDs. There is one primary and one or
   more secondary LSPs in each direction. When establishing a BFD
   session for an LSP, it is common for the primary LSP to choose the
   primary as the return path and the secondary LSP to choose the
   secondary as the return path. With the IPv4/IPv6 Tunnel sub-TLVs,
   operators don't have to specify a specific return LSP. They just
   need to specify from which tunnel the return LSP should be chosen,
   and specify the type (e.g., primary or secondary) of the return LSP.
   The egress LSR will then choose the proper return path.

   Use of IPv4/IPv6 RSVP Tunnel sub-TLVs permits MBB on return path of
   BFD session. If a specific RSVP session would be selected (with FEC
   containing LSP ID), return path would be interrupted if egress node
   would do MBB for the return path. This is due to the fact that MBB
   is based on signaling new LSP with different LSP ID and then
   deleting old LSP - after MBB selected return path would no longer be
   available. MBB is common occurrence as it is often used for changing
   LSP attributes, such as reserved bandwidth. With the extensions in
   [LSP-PING-RP], desired LSP can be selected without limiting use of
   MBB.


5. Encapsulation

   In this document, since the BFD control packet from the session
   terminator to initiator MUST be encapsulated in a MPLS label stack,
   it MUST have a well known destination port 3784 [BFD-IP].

6. Security Considerations

   Security considerations discussed in [BFD-MPLS], [BFD], [BFD-MHOP]
   and [RFC4379] apply to this document.

   Limitations on permitted return path LSPs specified [LSP-PING-RP]
   apply to extensions specified in this document.

7. IANA Considerations

   IANA is requested to make the following allocations from registries
   under its control.




Chen, et al.          Expires September 5, 2010               [Page 7]

Internet-Draft        BFD for MPLS Enhancement              March 2010


     7.1. Return code

   IANA is requested to assign a new return code as follows:

       Type #                  Value Field
       ------                  -----------
           11                  Backward direction session exists


     7.2. Session Control TLV

   IANA is requested to assign a new TLV type (TBD) from the range of
   0-16383. We suggest that the value 21 be assigned for the new RP TLV
   type.

       Type    Value Field
      -----    -----------
         21    Session Control


8. Acknowledgments

   The authors would like to thank Greg Mirsky, Xinchun Guo and Wei Cao
   for their review and comments to this document.

9. Contributors

   Vishwas Manral
   IP Infusion
   Almora, Uttarakhand
   India

   EMail: vishwas@ipinfusion.com


10. References

     10.1. Normative References

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

   [RFC 4379] K. Kompella., et al., "Detecting Multi-Protocol Label
             Switched (MPLS) Data Plane Failures", RFC 4379, February
             2006.



Chen, et al.          Expires September 5, 2010               [Page 8]

Internet-Draft        BFD for MPLS Enhancement              March 2010


   [BFD-MPLS] R. Aggarwal., et al., "BFD For MPLS LSPs", draft-ietf-
             bfd-mpls, working in progress.

   [LSP-PING-RP] M. Chen., et al., "Return Path Specified LSP Ping",
             draft-chen-mpls-return-path-specified-lsp-ping, working in
             progress.

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

   [MPLS-TP-TLV] Boutros, S., Bryant, S., Sivabalan, S., Swallow, G.,
             and D. Ward, "Definition of ACH TLV Structure",
             draft-ietf-mpls-tp-ach-tlv-01 (work in progress),
             February 2010.



     10.2. Informative References

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



























Chen, et al.          Expires September 5, 2010               [Page 9]

Internet-Draft        BFD for MPLS Enhancement              March 2010


Authors' Addresses

   Mach(Guoyi) Chen
   Huawei Technology Co., Ltd.
   No. 9 Xinxi Road
   Shangdi Information Industry Base
   Hai-Dian District, Beijing  100085
   China

   Email: mach@huawei.com

   So Ning
   Verizon Inc.
   2400 N. Glenville Rd.,
   Richardson, TX  75082

   Phone: +1 972-729-7905
   EMail: ning.so@verizonbusiness.com


   Ville Hallivuori
   Tellabs
   Sinimaentie 6 C
   FI-02630 Espoo, Finland

   EMail: ville.hallivuori@tellabs.com






















Chen, et al.          Expires September 5, 2010              [Page 10]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/