One document matched: draft-ashesh-bfd-stability-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes" ?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-ashesh-bfd-stability-00.txt"
ipr="trust200902">
<front>
<title abbrev="BFD Stability">BFD Stability</title>
<author fullname="Ashesh Mishra" initials="A" surname="Mishra">
<organization>Ciena Corporation</organization>
<address>
<postal>
<street>3939 North 1st Street</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>USA</country>
</postal>
<phone/>
<email>mishra.ashesh@gmail.com</email>
</address>
</author>
<author fullname="Santosh Pallagatti" initials="S" surname="Pallagatti">
<organization>Juniper Networks</organization>
<address>
<postal>
<street>Juniper Networks, Exora Business Park</street>
<city>Bangalore</city>
<region>Karnataka</region>
<code>560103</code>
<country>India</country>
</postal>
<phone>+</phone>
<facsimile/>
<email>santoshpk@juniper.net</email>
<uri/>
</address>
</author>
<author fullname="Mahesh Jethanandani" initials="M" surname="Jethanandani">
<organization>Ciena Corporation</organization>
<address>
<postal>
<street>3939 North 1st Street</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>USA</country>
</postal>
<phone/>
<facsimile/>
<email>mjethanandani@gmail.com</email>
<uri>www.ciena.com</uri>
</address>
</author>
<author fullname="Mach Chen" initials="M" surname="Chen">
<organization>Huawei</organization>
<address>
<postal>
<street/>
<city/>
<region/>
<code/>
<country/>
</postal>
<phone/>
<facsimile/>
<email>mach.chen@huawei.com</email>
<uri/>
</address>
</author>
<author fullname="Ankur Saxena" initials="A" surname="Saxena">
<organization>Ciena Corporation</organization>
<address>
<postal>
<street>3939 North 1st Street</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>USA</country>
</postal>
<phone/>
<facsimile/>
<email>ankurpsaxena@gmail.com</email>
<uri/>
</address>
</author>
<date day="30" month="June" year="2014"/>
<area>Network</area>
<workgroup>Routing Working Group</workgroup>
<keyword>Internet-Draft</keyword>
<abstract>
<t>This document describes extensions to the Bidirectional Forwarding
Detection (BFD) protocol to measure BFD stability. Specifically, it
describes a mechanism for detection of BFD frame loss, of delays in
frame transmitter and receiver engines, and of inter-frame delays that
might explain issues with a BFD session.</t>
</abstract>
<note title="Requirements Language">
<t>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 <xref
target="RFC2119">RFC 2119</xref>.</t>
</note>
</front>
<middle>
<section title="Introduction">
<t>The Bidirectional Forwarding Detection (BFD) protocol operates by
transmitting and receiving control frames, generally at high frequency,
over the datapath being monitored. In order to prevent significant data
loss due to a datapath failure, the tolerance for lost or delayed frames
(the Detection Time as described in RFC 5880) is set to the smallest
feasible value. In certain cases, this Detection Time is comparable to
the inter-frame delays caused by random network events such as frame
drops or frame processing (transmitter or receiver) delays.</t>
<t>This document proposes a mechanism to measure such transient effects
to detect instability in in the receive direction of the data path from
the session peer in addition to the datapath fault detection mechanisms
of BFD. Such a mechanism presents significant value with the ability to
measure the stability of BFD sessions and provides data to the
operators.</t>
<t>In addition to stability measurement, the information exchanged
between BFD peers can be used for rudimentary, but low-overhead,
authentication.</t>
</section>
<section title="BFD Null-Authentication TLV">
<t>The functionality proposed for BFD stability measurement is achieved
by appending the Null-Authentication TLV to the BFD control frame.</t>
<t>The Null-Authentication TLV (called 0-Auth in this document) extends
the existing BFD Authentication TLV structure by adding a new Auth-Type
of <IANA Assigned>. This TLV carries the Sequence Number for frame
loss measurement, and Sender Timestamps for delay measurements.</t>
<figure>
<artwork><![CDATA[ 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Auth Type | Auth Len | Auth Key ID | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Timestamp 1 (IFG only) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Timestamp 2 (IFG+TD only) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</figure>
<t>where:</t>
<t>Auth Type: The Authentication Type, which in this case is <IANA
assigned> (Null Authentication).</t>
<t>Auth Len: The length of the Authentication Section, in bytes. For
Loss Measurement only, the length is set to 4. For Loss and Inter-Frame
Gap measurements, the length is set to 8. For Loss, Inter-Frame Gap and
Transmission Delay on sender node, the length is set to 12.</t>
<t>Auth Key ID: The Authentication Key ID in use for this packet. This
MUST be set to zero on transmit, and ignored on receipt.</t>
<t>Reserved: This byte MUST be set to zero on transmit, and ignored on
receipt.</t>
<t>Sequence Number: This indicates the sequence number for this packet
and MUST be present in every 0-Auth TLV. This value is incremented by 1
for every frame transmitted while the session state is UP. A value of 0
indicates a request by sender to reset the sequence number correlation
logic at the receiver. The first frame transmitted by the sender MAY set
this field to 0. </t>
<t>Inter-Frame Gap (IFG) Mode:<list>
<t>Sender Timestamp 1 (IFG-ST): This is the Inter-Frame Gap Sender
Timestamp (IFG-ST) and is added at the last possible instance on the
sender (preferably on the PHY). The difference between two such
timestamps on consecutive frames is the Inter-Frame gap.</t>
</list></t>
<t>Inter-Frame Gap and Transmission Delay (IFG & TD) Mode:<list>
<t>Sender Timestamp 1 (TD-ST): This is the Transmission Delay Sender
Timestamp (TD-ST) and is added at the first possible instance on the
sender in the frame transmission engine. The difference between
TD-ST and the IFG-ST that follows the TD-ST is the Sender
Transmission Delay.</t>
<t>Sender Timestamp 2 (IFG-ST): This is the Inter-Frame Gap Sender
Timestamp (IFG-ST) and is added at the last possible instance on the
sender (preferably on the PHY). The difference between two such
timestamps on consecutive frames is the Inter-Frame gap.</t>
</list></t>
</section>
<section title="Theory of Operations">
<t>This mechanism allows operator to read three measures of stability of
BFD: Frame Loss, Inter-Frame Gap and Transmission Delay. The Receiver
Delay (interval between receipt of a frame on the PHY and the completion
of processing in the receiver engine) can be measured using timestamps
similar to the Sender Timestamps on the receiver node.</t>
<figure>
<artwork><![CDATA[+---------+ +---------+
| Sender |===================...=================| Receiver|
+---------+ +---------+
| | | |
TD-ST | | RD-RT
IFG-ST IFG-RT
]]></artwork>
</figure>
<section title="Frame Loss">
<t>This measurement counts the number of BFD control frames missed at
the receiver due to a transient change in the network such as
congestion. Frame-loss is detected by comparing the Sequence Number
field in the 0-Auth TLV in successive BFD CC frames. The Sequence
Number in each successive control frame generated on a BFD session by
the transmitter is incremented by one.</t>
<t>The first BFD Loss-Delay TLV processed by the receiver that has a
non-zero sequence number is used for bootstrapping the logic. Each
successive frame after this is expected to have a Sequence Number that
is one greater than the Sequence Number in the previous frame.</t>
</section>
<section title="Inter-Frame Gap">
<t>This measurement is the difference between the IFG-ST on any two
consecutive BFD CC frames that carry the 0-Auth TLV (IFG or IFG&TD
mode only) for a session. This is a key metric to determine transient
changes in stability of BFD transmission engine or to determine the
systems capability of handling the existing load. A significant
deviation of IFG from the negotiated transmission interval on the
local node indicates potential instabilities in the BFD transmission
engine. Based on the IFG measurements, the operator MAY take action to
configure the system to maintain normal operation of the node.</t>
<t>Similar IFG measurements on the receiver can be made using
timestamps (IFG-RT). In conjunction with IFG-ST measurements, these
can indicate delays caused by data-path. While a constant delay may
not be indicator of instability, large transient delays can decrease
the BFD session stability significantly.</t>
</section>
<section title="Frame Transmission Delay">
<t>This measurement (TD) is the interval between the timestamp (TD-ST)
when the frame transmission timer expires, triggering the BFD control
frame generation, and the timestamp (IFG-TD) when the frame reaches
the last level in the frame processing logic on the transmitter where
the frame can be manipulated. Large variations in the TD measurements
over time are indicative of non-deterministic transmission behavior of
the BFD engine and can be a pre-cursor to BFD engine instability.</t>
<t>Similar measurements for Receiver Delay (RD) can be made using
IFG-RT and RD-RT timestamps, and indicate similar instabilities on the
BFD receiver engine.</t>
</section>
</section>
<section title="IANA Requirements">
<t>IANA is requested to assign new Auth-Type for the Null-Authentication
TLV for BFD Stability Measurement. The following number is
suggested.</t>
<t>Value Meaning</t>
<t>6 Null-Authentication TLV</t>
</section>
<section title="Security Consideration">
<t>Since this method uses an authentication TLV to achive the
functionality, usage of this TLV will prevent the use of other
authentication TLVs.</t>
</section>
<section title="Acknowledgements">
<t>Nobo Akiya, Jeffery Haas, Peng Fan, Dileep Singh, Basil Saji, Sagar
Soni and Mallik Mudigonda also conributed to this document. </t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.5880"?>
<?rfc include="reference.RFC.2119"?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 19:32:36 |