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

Versions: 00

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]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/