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]