One document matched: draft-ashesh-bfd-stability-02.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-02.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>

        <uri>www.ciena.com</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="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>

    <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="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>

    <date day="23" month="April" year="2015"/>

    <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.</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. </t>

      <t>This document proposes a mechanism to detect lost frames in a BFD
      session 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>
    </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.</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                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Reserved for Future                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Reserved for Future                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></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. 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>Reserved for Future: For future extensions. MUST be set to 0 if not
      used. </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>
    </section>

    <section title="Theory of Operations">
      <t>This mechanism allows operator to measure the loss of BFD CC frames.
      </t>

      <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="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-20262026-04-23 19:29:52