Network Working Group M. Chen Internet-Draft Z. Wang Intended status: Standards Track Huawei Technologies Co.,Ltd Expires: January 2, 2012 L. Guo China Telecom M. Binderberger July 1, 2011 Bidirectional Forwarding Detection (BFD) for Interface draft-chen-bfd-interface-00 Abstract This document describes how application clients can request IP-based Bidirectional Forwarding Detection (BFD) sessions while either being IP agnostic themselves or while dealing with IP unnumbered interfaces. A dedicated well-known multicast IP address 224.XXX.XXX.XXX is used as the destination IP address of the BFD packets when running BFD for interface. It allows for BFD sessions on interfaces that may have no IP addresses, either because the interface is unnumbered or because the layer 3 protocol status of the interfaces is not up yet. One application of BFD for interface is to run BFD over LAG/Bundle component links. An example will be given in this document. Requirements Language 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]. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." Chen, et al. Expires January 2, 2012 [Page 1] Internet-Draft BFD for Interface July 2011 This Internet-Draft will expire on January 2, 2012. Copyright Notice Copyright (c) 2011 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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Chen, et al. Expires January 2, 2012 [Page 2] Internet-Draft BFD for Interface July 2011 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . . 4 3. Extensions to BFD . . . . . . . . . . . . . . . . . . . . . . . 5 4. Implementation example for LAG . . . . . . . . . . . . . . . . 6 5. Security Consideration . . . . . . . . . . . . . . . . . . . . 6 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 8.1. Normative References . . . . . . . . . . . . . . . . . . . 7 8.2. Informative References . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 Chen, et al. Expires January 2, 2012 [Page 3] Internet-Draft BFD for Interface July 2011 1. Introduction The Bidirectional Forwarding Detection (BFD) protocol RFC 5880 [RFC5880] provides a mechanism for liveness detection of arbitrary paths between systems. It is intended to provide low-overhead, short- duration detection of failures in the path between adjacent forwarding engines, including the interfaces, data link(s), and to the extent possible the forwarding engines themselves. Although BFD can be used for detecting failures of the path between two interfaces, normally the application clients are not the interfaces themselves but layer 3 applications like Open Shortest Path First (OSPF) [RFC2328] or Border Gateway Protocol (BGP)[RFC4271]. There are scenarios though that may require running BFD directly on the interfaces and to associate the BFD session status with the status of the interfaces, and consequently taking down or bringing up the interfaces rapidly by BFD. One example of this is a Link Aggregation Group (LAG) or bundle interface that consists of multiple component interfaces; it requires to detect the status of each component interface hence to block the faulty interfaces and avoid unnecessary packets loss, or take down the LAG/ bundle interface when the number/bandwidth of failed component interfaces reaches a preconfigured threshold. This can be achieved by establishing separate BFD session for each pair of component interfaces to detect the failures, and the interfaces or the LAG management module owning these interfaces are clients served by those BFD sessions. 2. Problem Statement IP addresses (source and destination IP address) are necessary when setting up a BFD session. But for an unnumbered interface there is no dedicated IP address configured, for a LAG component interfaces it's possible that the interface is not IP activated yet. Hence a BFD session can not be established due to lack of either the destination IP address or Address Resolution Protocol (ARP) on an Ethernet interface. Therefore it is required that BFD can run on the interfaces without knowledge of an IP address specific for the interface and without the need to use ARP. In addition, when the interface is itself the client of the BFD session, then the status of the interfaces will be associated with the status of the BFD session. There may be a deadlock situation since BFD session down may take down the interfaces (e.g., layer 3 protocol down), and subsequently BFD packets, including other control Chen, et al. Expires January 2, 2012 [Page 4] Internet-Draft BFD for Interface July 2011 protocols packets (e.g. ARP) that are tightly coupled with the status of the interface, cannot be transmitted between the pair of interfaces, thus failing to bring up the interfaces. To avoid the deadlock BFD packets SHOULD NOT be blocked by the layer N protocol status of the interface when the application depends on the BFD status to enable layer N of the interface. If this cannot be achieved then the BFD status MUST be ignored by the application when bringing up an interface. The BFD status can then be used afterwards to bring the interface down. 3. Extensions to BFD This document does not change the format of BFD control packets and the BFD state machine defined in RFC 5880 [RFC5880]. Currently, only asynchronous mode is considered in this document. To solve the issues described in Section 2, this document introduces a new concept of using Multicast BFD (M-BFD). M-BFD uses a dedicated well-known multicast IP address (224.XXX.XXX.XXX, to be assigned by IANA) as the destination IP address when sending BFD packets. With this extension, a BFD session can be setup for the interfaces that are IP unnumbered. In addition it will not require to use address resolution (ARP) before sending the BFD packets. When sending BFD packets, the destination address MUST be set to 224.XXX.XXX.XXX, the destination UDP port is set as defined in RFC 5881 [RFC5881] for BFD control packets. The BFD packets are sent to the specified interface that is associated with the BFD session. The BFD source address MUST be an IP address that belongs to the sending system. If no such address is available then 0.0.0.0 should be used as a source address. When BFD for interface is configured on an interface, it MUST be able to receive the BFD packets with destination IP address set to the well-known multicast IP address (e.g., 224.XXX.XXX.XXX) and send them to the BFD module for further processing. Due to the potential deadlock problem described in section 2 application clients MUST be able to proceed without an UP status message from BFD. Otherwise interoperability is at risk. It may be desirable for the application client to wait for BFD reporting back an UP status; in this case it is recommended to introduce a configuration option to allow this wait-for-BFD behaviour. Chen, et al. Expires January 2, 2012 [Page 5] Internet-Draft BFD for Interface July 2011 4. Implementation example for LAG The following is an example how the mechanism above allows to use BFD to activate and deactivate LAG (bundle) component links. Some details are implementation specific and are NOT part of this standard. The interface states as well as the details of a LAG interface are controlled by the Interface Management Module (IMM). When BFD is enabled by configuration for a particular LAG then IMM requests a M-BFD session for all interfaces that are configured to be components of the LAG interface. A new interface status "BFD down" is defined. When the status of interface is associated with the status of the BFD session that is configured on the interface, if the BFD session is down, it will notify the interface management module to set the status of interface to "BFD down", and for upper layer protocols, the interface presents as in down status. When the BFD session is UP, it will notify the interface management module to clear the "BFD down" status. Once a LAG component link has reached the "BFD up" status it becomes an active part of the Bundle. When the status changes to "BFD down" the component link is removed from the Bundle. For this to work it is mandatory that whatever the status of an interface is, "BFD down" or not, the BFD packet transmission and reception is not impacted by this status. 5. Security Consideration This document does not introduce any additional security issues and the security mechanisms defined in [RFC5880] apply in this document. 6. IANA Considerations The IANA is required to assign a well-known multicast IP address: "224.XXX.XXX.XXX". 7. Acknowledgements 8. References Chen, et al. Expires January 2, 2012 [Page 6] Internet-Draft BFD for Interface July 2011 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD)", RFC 5880, June 2010. [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, June 2010. 8.2. Informative References [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006. Authors' Addresses Mach(Guoyi) Chen Huawei Technologies Co.,Ltd No. 3 Xinxi Road, Shang-di, Hai-dian District Beijing, 100085 China Email: mach@huawei.com Zuliang Wang Huawei Technologies Co.,Ltd No. 3 Xinxi Road, Shang-di, Hai-dian District Beijing, 100085 China Email: liang_tsing@huawei.com Liang Guo China Telecom Guangzhou Guangzhou China Email: guoliang@gsta.com Chen, et al. Expires January 2, 2012 [Page 7] Internet-Draft BFD for Interface July 2011 Marc Binderberger Lausanne, Switzerland Email: marc@sniff.de Chen, et al. Expires January 2, 2012 [Page 8]