<?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-am-bfd-performance-00" ipr="trust200902">
  <front>
    <title abbrev="">BFD Performance Measurement</title>

    <author fullname="Ashesh Mishra" initials="A" surname="Mishra">
      <organization>O3b Networks</organization>

      <address>
        <postal>
          <street/>

          <city/>

          <region/>

          <code/>

          <country/>
        </postal>

        <phone/>

        <email>mishra.ashesh@gmail.com</email>

        <uri/>
      </address>
    </author>

    <author fullname="Mahesh Jethanandani" initials="M" surname="Jethanandani">
      <organization/>

      <address>
        <postal>
          <street/>

          <city/>

          <region/>

          <code/>

          <country/>
        </postal>

        <phone/>

        <facsimile/>

        <email>mjethanandani@gmail.com</email>

        <uri/>
      </address>
    </author>

    <date day="21" month="November" year="2017"/>

    <abstract>
      <t>This document describes an extension to the Bidirectional Forwarding
      Detection (BFD) protocol to determine the optimal BFD transmit interval
      for links with high one-way delay.</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 (<xref
      target="RFC5880">BFD)</xref> 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 in the
      Detection Time, as defined in <xref target="RFC5880">BFD</xref> is set
      to the smallest feasible value.</t>

      <t>This document proposes a mechanism to determine the smallest BFD
      transmit interval that can be supported on the link. This is achieved by
      actively measuing the one-way delay for each BFD session and setting the
      BFD session intervals based on the measured delay. This allows the BFD
      session to adapt to the fastest rate feasible on the current active
      path.</t>
    </section>

    <section title="Use Cases">
      <t>To ensure stability, the BFD interval is typically set to value
      greater than the one-way delay of the link. This value is currently
      manually tuned based on the largest one-way delay in the set of links
      over which the session can be established.</t>

      <t>The method described in this proposal is useful in networks where the
      network latency is high, or varies with time. Trans-oceanic links and
      connectivity over geo-synchronous satellites are typical examples of
      links where the latency is high and the difference in latency on primary
      and backup paths can be significant.</t>

      <t>Another use-case is connectivity using satellites in mid-earth orbit
      (MEO) or low-earth orbit (LEO). In these systems the one-way delay,
      while it is low (25msec to 150 msec), varies with time. This variation,
      based on various factors, can be as high as 30 msec. With mobile
      receivers, such as ships, the delay when using such connectivity can be
      non-trivial to predict. This requires an automated method to determine
      the optimal BFD interval to allow fastest possible recovery in case of
      failure.</t>

      <t>Many networks employ the use of diverse link types for redundancy
      where each link has significantly different link characteristics. For
      example, using geo-stationary orbit (GEO) satellite backup for MEO/LEO
      connectivity, or using fibre backup for MEO connectivity. The end-to-end
      BFD sessions for services running on top of the diverse transport will
      benefit from adaptive BFD rate.</t>
    </section>

    <section title="BFD Performance TLV">
      <t>The functionality proposed for BFD performance measurement is
      achieved by proposing a new BFD Performance TLV to the BFD control
      frame. This TLV leverages the delay measurement method defined in <xref
      target="RFC6374">RFC 6374</xref>. As BFD Version 1 control frame does
      not have unused flags, the BFD Performance TLV overloads the BFD
      Authentication Flag and uses a new auth type BFDP-AUTH-TYPE (code-point
      TBA). The BFD Performance TLV merges the MPLS delay measurement message
      with the BFD authentication TLV (while removing fields that are not
      required for this application)</t>

      <t><figure title="Figure 1: BFD Performance TLV">
          <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    |Version| Flags |  Control Code |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |  QTF  |  RTF  | RPTF  |              Reserved                 |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                           Timestamp 1                         |
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                           Timestamp 2                         |
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                           Timestamp 3                         |
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                           Timestamp 4                         |
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
        </figure> where:</t>

      <t>Auth Type: The Authentication Type, which in this case is
      BFDP-AUTH-TYPE (value to be assigned).</t>

      <t>Auth Len: The length of the Authentication Section, in bytes.</t>

      <t>Version: Currently set to 0.</t>

      <t>Flags: As specified in Section 3.1 of <xref target="RFC6374">RFC
      6374</xref>. The T flag is set to 1.</t>

      <t>Control Code: As specified in Section 3.1 of <xref
      target="RFC6374">RFC 6374</xref>.</t>

      <t>QTF: Querier Timestamp Format. The format of the timestamp values
      written by the querier, as specified in Section 3.4 of <xref
      target="RFC6374">RFC 6374</xref>.</t>

      <t>RTF: Responder Timestamp Format. The format of the timestamp values
      written by the responder, as specified in Section 3.4 of <xref
      target="RFC6374">RFC 6374</xref>.</t>

      <t>RPTF: Responder's Preferred Timestamp Format. The timestamp format
      preferred by the responder, as specified in Section 3.4 of <xref
      target="RFC6374">RFC 6374</xref>.</t>

      <t>Timestamp 1-4: Referring to Section 2.4 of <xref target="RFC6374">RFC
      6374</xref>, when a query is sent from A, Timestamp 1 is set to T1 and
      the other timestamp fields are set to 0. When the query is received at
      B, Timestamp 2 is set to T2. At this point, B copies Timestamp 1 to
      Timestamp 3 and Timestamp 2 to Timestamp 4, and re-initializes Timestamp
      1 and Timestamp 2 to 0. When B transmits the response, Timestamp 1 is
      set to T3. When the response is received at A, Timestamp 2 is set to T4.
      The actual formats of the timestamp fields written by A and B are
      indicated by the Querier Timestamp Format and Responder Timestamp Format
      fields respectively.</t>

      <t>The mapping of timestamps to the Timestamp 1-4 fields is designed to
      ensure that transmit timestamps are always written at the same fixed
      offset in the packet, and likewise for receive timestamps. This property
      is important for hardware processing.</t>
    </section>

    <section title="Theory of Operations">
      <t>This delay measurement follows the method defined in Section 2.4 of
      <xref target="RFC6374">RFC 6374</xref>.</t>

      <t>The message is classified using the BFD authentication method defined
      in <xref target="RFC5880">RFC5880</xref>.</t>

      <t>Method for determining the optimal BFD interval for a link with
      certain delay charateristics is implementation specific and beyond the
      scope of this document. </t>
    </section>

    <section title="IANA Requirements">
      <t>Requesting new BFD Authentication Type for BFD Performance TLV.</t>
    </section>

    <section title="Security Consideration">
      <t>Other than concerns raised in <xref target="RFC5880">BFD</xref>,
      there are no new concerns with this proposal.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include='reference.RFC.5880'?>

      <?rfc include='reference.RFC.2119'?>

      <?rfc include='reference.RFC.6374'?>
    </references>
  </back>
</rfc>
