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]