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]