Network working group M. Chen Internet Draft Huawei Category: Standards Track N. So Created: October 19, 2009 Verizon Expires: April 2010 V. Hallivuori Tellabs BFD for MPLS LSPs Enhancement draft-chen-mpls-bfd-enhancement-00.txt 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. 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Chen, et al. Expires April 19, 2010 [Page 1] Internet-Draft BFD for MPLS Enhancement October 2009 Please review these documents carefully, as they describe your rights and restrictions with respect to this document. 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 return 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 LSPs 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. 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.....................................5 4.2. The usage of IPv4/IPv6 RSVP Tunnel sub-TLVs.............6 5. Security Considerations......................................7 6. IANA Considerations..........................................7 6.1. Return code.............................................7 6.2. Session Control TLV.....................................7 7. Acknowledgments..............................................7 8. References...................................................8 8.1. Normative References....................................8 8.2. Informative References..................................8 Authors' Addresses..............................................9 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 April 19, 2010 [Page 2] Internet-Draft BFD for MPLS Enhancement October 2009 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/optical 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. 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 one direction switches while the other does not. This can cause unexpected operational problems. Chen, et al. Expires April 19, 2010 [Page 3] Internet-Draft BFD for MPLS Enhancement October 2009 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), 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] apply here. In addition to that, a RP TLV 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. Chen, et al. Expires April 19, 2010 [Page 4] Internet-Draft BFD for MPLS Enhancement October 2009 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 preceding [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) shall initiate signaling. 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 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]. 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 Chen, et al. Expires April 19, 2010 [Page 5] Internet-Draft BFD for MPLS Enhancement October 2009 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. 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 Chen, et al. Expires April 19, 2010 [Page 6] Internet-Draft BFD for MPLS Enhancement October 2009 [LSP-PING-RP], desired LSP can be selected without limiting use of MBB. 5. 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. 6. IANA Considerations IANA is requested to make the following allocations from registries under its control. 6.1. Return code IANA is requested to assign a new return code as follows: Type # Value Field ------ ----------- 11 Backward direction session exists 6.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 7. Acknowledgments The authors would like to thank Xinchun Guo and Wei Cao for their review and comments to this document. Chen, et al. Expires April 19, 2010 [Page 7] Internet-Draft BFD for MPLS Enhancement October 2009 8. References 8.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. [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. 8.2. Informative References Chen, et al. Expires April 19, 2010 [Page 8] Internet-Draft BFD for MPLS Enhancement October 2009 Authors' Addresses Mach(Guoyi) Chen Huawei Technologies Co., Ltd KuiKe Building, No.9 Xinxi Rd., Hai-Dian District, Beijing 100085 P.R. China EMail: mach@huawei.com So Ning Verizon 2400 N. Glem Ave., Richerson, 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 April 19, 2010 [Page 9]