BFD Working Group X. Dai, Ed. Internet-Draft L. Zhang Intended status: Informational H. Wei Expires: September 2, 2010 W. Wu ZTE Corpoporation Mar 1, 2010 BFD extensions for variable length packets draft-dz-bfd-extensions-for-vl-packets-00 Abstract This document extends BFD mechanism to support detection function for packets with variable lengths. Through dynamically changing the length of BFD packets, it can detect both traditional faults such as link failure or route fault, as well as non-forwarding problem for packets with a length in a special range, which maybe caused by equipment's internal defects. 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 September 2, 2010. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. Dai, et al. Expires September 2, 2010 [Page 1] Internet-Draft BFD extensions for vl packets Mar 2010 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 BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions used in this document . . . . . . . . . . . . . . 4 2.1. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 4 3. Motivations . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. BFD Extensions . . . . . . . . . . . . . . . . . . . . . . . . 6 5. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 13 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 9.1. Normative references . . . . . . . . . . . . . . . . . . . 14 9.2. Informative References . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 Dai, et al. Expires September 2, 2010 [Page 2] Internet-Draft BFD extensions for vl packets Mar 2010 1. Introduction The Bidirectional Forwarding Detection protocol (BFD) 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. It operates independently of media, data protocols, and routing protocols. An additional goal is to provide a single mechanism that can be used for liveness detection over any media, at any protocol layer, with a wide range of detection times and overhead, to avoid a proliferation of different methods. BFD uses a three-way handshake mechanism to establish a BFD session, for detailed procedure refer to BFD-base document[BFD-base]. BFD is a simple hello protocol, in many respects, it's similar to the detection components of well-known routing protocol. A pair of systems transmit BFD packets periodically over each path between the two systems. If a system stops receiving BFD packets for long enough, the detected path is assumed to have failed. BFD control packet has a mandatory section and an optional authentication section. The mandatory section is 24-bytes long, and BFD control packets are sent in an encapsulation appropriate to the enviroment. This document extends BFD mechanism to support detection function for packets with variable lengths. Through dynamically changing the length of BFD packets, it can detect both traditional faults such as link failure or route fault, as well as non-forwarding problem for packets with a length in a special range. Dai, et al. Expires September 2, 2010 [Page 3] Internet-Draft BFD extensions for vl packets Mar 2010 2. 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. 2.1. Abbreviations BFD: Bidirectional Forwarding Detection Dai, et al. Expires September 2, 2010 [Page 4] Internet-Draft BFD extensions for vl packets Mar 2010 3. Motivations In actual application networks, there maybe several transmission equipments between BFD neighbours, sometimes may have switching networks. Because data packets through the detected path may be of different lengths, there may exsit such situations that packets with some lengths can be normally forwarded but packets with other lengths can't be forwarded. For example, under some specific implementation, packets within a special range may not be forwarded as a result of packet forwarding engine fault. But the normal BFD packets can still be forwarded, because BFD packet length is out of the special packet range. In this case, the BFD session is UP, but the customer service is DOWN. So there is a need to detect this kind of failure and implement Self- healing or switch, in order to avoid interruption of traffic transmission. However, traditional BFD mechanism can't resolve such problem, as a standard BFD control packet (no authentication section) is only 24 bytes. So BFD can't meet the detection requirements described in the former section. That is to say, if service packets are longer than BFD packets, exsiting BFD mechanism can't detect such forwarding problem when these packets meet forwarding failures. To resolve such problem, this document extends BFD function to make it be capable of negotiating the length and change regulation of BFD packets. Through dynamically changing the length of BFD packets, BFD mechanism can detect forwarding problems for packets with different lengths and implenments appropriate protection operations under a failure condition. It's main characteristic consists in verifying the connectivity between BFD neighbours through transmitting BFD packets whose lengths change periodically, and switch to a backup path as soon as detection times out. This protection may be completed in combination with fast reroute mechanism. The extended BFD mechanism in this document can detect forwarding failures for packets with a length in a special range, and implements protection scheme upon detecting such failures to avoid traffic interruption, thereby boosts up the flexibility of BFD. Dai, et al. Expires September 2, 2010 [Page 5] Internet-Draft BFD extensions for vl packets Mar 2010 4. BFD Extensions In order to support transmitting BFD packets with variable lengths, there is a need to extend the standard BFD packets defined in BFD- base document[BFD-base], allowing BFD neighbours to negotiate the transmission regulation of BFD packets. Involved Extensions to BFD include: revise version number, extend the meaning of the P and F flags, and add a field used for variable length packets negotiation. This new added field contains the following contents: Option, Reserved, Step length, Transmitted number, Max length and Min length. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Vers | Diag |Sta|P|F|C|A|D|M| Detect Mult | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | My Discriminator | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Your Discriminator | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Desired Min TX Interval | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Required Min RX Interval | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Required Min Echo RX Interval | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | optional authentication section | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- |option | Reserved | step length | TX Num | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max Length | Min Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | padding | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: Format of extened BFD packets Version(Vers): the version number of the protocol. In this document, this field should be set to 2, indicating that BFD supports detection function for packets with variable lengths. Dai, et al. Expires September 2, 2010 [Page 6] Internet-Draft BFD extensions for vl packets Mar 2010 P: if set, the transmitting system is requesting a parameter change, including variable-length detection parameters negotiation, also it is expecting a packet with F bit in reply. Otherwise, set to 0. F: if set, the transmitting system is responding to a received BFD control packet that had a P bit set. Otherwise, set to 0. Authentication: this section is optional as specified in BFD-Base document. Option: used to support BFD Extensions 0-- no Extension 1-- supports detection function for packets with variable lengths 2~15-- Reserved for future use Reserved: for future use. Step length: change gradient of BFD control packets that local system transmits, in bytes. Transmitted packets number(TX Num): the number of BFD control packets with a length that local system will transmit succesively. Max length of BFD packets(Max Length): the max length of BFD control packets that local system can support, in bytes. Min length of BFD packets (Min Length): the min length of BFD control packets that local system can support, in bytes. padding: this field is used in BFD packets to expand packet length; In order to be convenient for check and calculation, it is proposed to be all 0 in this document. Dai, et al. Expires September 2, 2010 [Page 7] Internet-Draft BFD extensions for vl packets Mar 2010 5. Theory of Operation BFD's detection function for packets with variable lengths is dynamically and regularly changing the length of BFD packets, to detect forwarding problem for packets with different lengths. This section is about operational procedures for the extended BFD mechanism. The first step is to negotiate BFD parameters, which includes standard parameters defined in BFD-base document as well as required parameters for detection function for packets with variable lengths. This step should be completed during the connection period for BFD. With respect to detection function for packets with variable lengths, It mainly negotiates the length intervals and change regulation for packets with variable lengths. When it is a request to negotiate such parameters, the P flag in BFD packets should be set to 1, and wish to receive a packet with F bit set. Each field in extended BFD packets are set as described below: Version: it is set to 2 in this document. P: It is set to 1, indicating that the transmitting system is requesting a parameter change, including variable-length detection parameters negotiation, also it is expecting a packet with F bit in reply. F: It is set to 1, indicating that the transmitting system is responding to a received BFD control packet that had a P bit set. Note that P flag and Fflag can't be 1 simultaneitly. Option: it is set to 1, indicating that this is a BFD packet which supports detection function for packets with variable lengths. Step length: change gradient of BFD packets that local system transmits. Actual step length requires negotiation with its peer. Step length=min( step length that local system supports, step length that the peer notified) Generally speaking , the longer the step length is , the faster a system detects a failure, whereas the worse the accuracy of packets length in trouble can be obtained. In turn, the slower one can detect a failure , and the higher the accuracy obtained. Transmitted number of BFD packets: it's the number of packets transmitted for a specical length , and it also requires a Dai, et al. Expires September 2, 2010 [Page 8] Internet-Draft BFD extensions for vl packets Mar 2010 negotiation with its peer. Transmitted number= min(transmitted number of BFD packets in local system, transmitted number of BFD packets the peer notified) Max length of BFD control packets: To notify its peer of the max length of control packets that local system can support, also needs to negotiate with its peer. Max length of BFD control packets=max( max length of BFD packets that local system supports , max length of control packets that the peer notified) Min length of BFD control packets: To notify its peer of the min length of BFD packets that it can support, also need to negotiate with its peer. In addition, the min length should not be less than the length of standard BFD packets in BFD-base document. Min length of BFD control packets=min( min length of BFD packets that local system supports, min length of control packets that the peer notified) Detection time is dependent on the regulation of BFD control packets transmitted . This document proposes a unidirectional repeatable algorithm, that is to say, each system first sends BFD control packets with Min length according to the negotiated transmitted packets number, then periodically sends control packets with the next length according to the negotiated step length, continue this kind of increment, and return to sends packets with Min length after coming up to the Max length. The selection for transmission regulation of BFD packets is shown as the figure below: Dai, et al. Expires September 2, 2010 [Page 9] Internet-Draft BFD extensions for vl packets Mar 2010 length ^ | . BFD packet | Max Length + ... ... | | ... ... | | ... ... | Min Length + ... ... | - - - - - - - - - - - - - - - - - ->time Figure 2: transmission regulation of BFD packets After successful negotiation described above, both ends succesivelly send BFD control packets according to the negotiated parameters. BFD control packets must be complete, that is to say, the min length of BFD packets must not be less than standard BFD control packets. One can insert padding after the standard BFD packets in order to obtain packets that is longer than the standard packets. As soon as detection times out, BFD indicates link DOWN failure to the client, and then implements appropriate operation, such as switch to a backup path. Upon receiving a BFD control packet, one can record the length of the last received packet. By doing this, one can fix the fault length interval when detetion times out. In order to make this kind of detection more efficient, operators can set the length interval of BFD control packets according to service characteristics. The key technique of this document consists in selecting proper change gradient, this can be selected according to sevice type or characteristics. Generally, if the gradient is too large, one can not determine accurately in which length interval does the failure occur; otherwise, if it is too small, it may take more time to find in which length interval does the failure occurs, and also will affect real-timing of BFD mechanism. Dai, et al. Expires September 2, 2010 [Page 10] Internet-Draft BFD extensions for vl packets Mar 2010 6. Security Considerations Security considerations discussed in [BFD-base], [BFD-1HOP] and [BFD- MHOP] apply to this document. Dai, et al. Expires September 2, 2010 [Page 11] Internet-Draft BFD extensions for vl packets Mar 2010 7. IANA Considerations TBD. Dai, et al. Expires September 2, 2010 [Page 12] Internet-Draft BFD extensions for vl packets Mar 2010 8. Acknowledgement TBD. Dai, et al. Expires September 2, 2010 [Page 13] Internet-Draft BFD extensions for vl packets Mar 2010 9. References 9.1. Normative references 9.2. Informative References [BFD-1HOP] Katz, D. and D. Ward, "BFD for IPv4 and IPv6 (Single Hop)". [BFD-MHOP] Katz, D. and D. Ward, "BFD for Multihop Paths". [BFD-base] Katz, D. and D. Ward, "Bidirectional Forwarding Detection". Dai, et al. Expires September 2, 2010 [Page 14] Internet-Draft BFD extensions for vl packets Mar 2010 Authors' Addresses Xuehui Dai (editor) ZTE Corpoporation 4F,RD Building 2,Zijinghua Road Yuhuatai District,Nanjing 210012 P.R.China Phone: +86 025 52877612 Email: dai.xuehui@zte.com.cn Lei Zhang ZTE Corpoporation 3F,RD Building 1,Zijinghua Road Yuhuatai District,Nanjing 210012 P.R.China Phone: +86 025 52870438 Email: zhang.lei31@zte.com.cn Hongbo Wei ZTE Corpoporation 3F,RD Building 1,Zijinghua Road Yuhuatai District,Nanjing 210012 P.R.China Phone: +86 025 52870438 Email: wei.hongbo@zte.com.cn Wantao Wu ZTE Corpoporation 3F,RD Building 1,Zijinghua Road Yuhuatai District,Nanjing 210012 P.R.China Phone: +86 025 52870438 Email: wu.wantao@zte.com.cn Dai, et al. Expires September 2, 2010 [Page 15]