One document matched: draft-ietf-bfd-intervals-01.xml

<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
     which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs), 
     please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
     (Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space 
     (using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->


<rfc category="info" docName="draft-ietf-bfd-intervals-01" ipr="trust200902">
  <!-- category values: std, bcp, info, exp, and historic
     ipr values: full3667, noModification3667, noDerivatives3667
     you can add the attributes updates="NNNN" and obsoletes="NNNN" 
     they will automatically be output with "(if approved)" -->

  <!-- ***** FRONT MATTER ***** -->

  <front>
    <title abbrev="Common Interval Support in BFD">
    Common Interval Support in BFD
    </title>

    <!-- add 'role="editor"' below for the editors if appropriate -->
    <!-- Another author who claims to be an editor -->

    <author fullname="Nobo Akiya" initials="N."
            surname="Akiya">
      <organization>Cisco Systems</organization>
      <address>
        <email>nobo@cisco.com</email>
      </address>
    </author>

    <author fullname="Marc Binderberger" initials="M."
            surname="Binderberger">
      <organization>Cisco Systems</organization>
      <address>
        <email>mbinderb@cisco.com</email>
      </address>
    </author>

    <author fullname="Greg Mirsky" initials="G."
            surname="Mirsky">
      <organization>Ericsson</organization>
      <address>
        <email>gregory.mirsky@ericsson.com</email>
      </address>
    </author>
    
    <date year="2014" />

    <area>BFD Working Group</area>
    <workgroup>Internet Engineering Task Force</workgroup>

    <!-- WG name at the upperleft corner of the doc,
    IETF is fine for individual submissions.  
    If this element is not present, the default is "Network Working Group",
    which is used by the RFC Editor as a nod to the history of the IETF. -->

    <keyword>BFD</keyword>
    <keyword>hardware</keyword>
    <keyword>interval</keyword>
    <keyword>timer</keyword>

    <!-- Keywords will be incorporated into HTML output
         files in a meta tag but they have no effect on text or nroff
         output. If you submit your draft to the RFC Editor, the
         keywords will be used for the search engine. -->

    <abstract>
    <t>Some BFD implementations may be restricted to only support several
    interval values. When such BFD implementations speak to each other,
    there is a possibility of two sides not being able to find a common
    interval value to run BFD sessions.</t>

    <t>This document defines a small set of interval values for BFD that we
    call "Common intervals", and recommends implementations to support
    the defined intervals. This solves the problem of finding an interval
    value that both BFD speakers can support while allowing a simplified
    implementation as seen for hardware-based BFD. It does not restrict an
    implementation from supporting more intervals in addition to the
    Common intervals.</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 standard <xref target="RFC5880" /> describes how to calculate
    the transmission interval and the detection time. It does not make
    any statement though how to solve a situation where one BFD speaker
    cannot support the calculated value. In practice this may not been a
    problem as long as software-implemented timers have been used and as
    long as the granularity of such timers was small compared to the
    interval values being supported, i.e. as long as the error in the
    timer interval was small compared to 25 percent jitter.</t>

    <t>In the meantime requests exist for very fast interval values,
    down to 3.3msec for MPLS-TP. At the same time the requested scale
    for the number of BFD sessions in increasing. Both requirements have
    driven vendors to use Network Processors (NP), FPGAs or other
    hardware-based solutions to offload the periodic packet transmission
    and the timeout detection in the receive direction. A potential
    problem with this hardware-based BFD is the granularity of the
    interval timers. Depending on the implementation only a few
    intervals may be supported, which can cause interoperability
    problems. This document proposes a set of interval values that
    should be supported by all implementations. Details are laid
    out in the following sections.</t>
    </section>

    <section title="The problem with few supported intervals">
    <t>Let's assume vendor "A" supports 10msec, 100msec and 1sec interval
    timers in hardware. Vendor "B" supports every value from 20msec
    onward, with a granularity of 1msec. For a BFD session "A" tries to
    set up the session with 10msec while "B" uses 20msec as the value for 
    RequiredMinRxInterval and DesiredMinTxInterval. <xref target="RFC5880" />
    describes that the negotiated value for Rx and Tx is 20msec. But system
    "A" is not able to support this. Multiple ways exist to resolve the
    dilemma but none of them is without problems.

    <list style="letters">
      <t>Realizing that it cannot support 20msec, system "A" sends out a
      new BFD packet, advertising the next larger interval of 100msec
      with RequiredMinRxInterval and DesiredMinTxInterval. The new
      negotiated interval between "A" and "B" then is 100msec, which is
      supported by both systems. The problem though is that we moved
      from the 10/20msec range to 100msec, which has far deviated from
      operator expectations.</t>

      <t>System "A" could violate <xref target="RFC5880" /> and use the
      10msec interval for the Tx direction. In the receive direction it
      could use an adjusted multiplier value
      M' = 2 * M to match the correct detection time.
      Now beside the fact that we explicitly violate
      <xref target="RFC5880" /> there may be the problem that system "B"
      drops up to 50% of the packets; this could be the case when "B" uses
      an ingress rate policer to protect itself and the policer would be
      programmed with an expectation of 20msec receive intervals.</t>
    </list>

    The example above could be worse when we assume that system
    "B" can only support a few timer values itself. Let's assume "B"
    supports "20msec", "300msec" and "1sec". If both systems would adjust
    their advertised intervals, then the adjustment ends at 1sec.

    The example above could even be worse when we assume that system
    "B" can only support "50msec", "500msec" and "2sec". Even if both
    systems walk their supported intervals, the two systems will never
    be able to agree on a interval to run any BFD sessions.</t>
    </section>

    <section title="Well-defined, common intervals">
    <t>The problem can be reduced by defining interval values that are
    supported by all implementations.  Then the adjustment mechanism
    could find a commonly supported interval without deviating too much
    from the original request.</t>

    <t>In technical terms the requirement is as follows: a BFD
    implementation SHOULD support all values in the set of Common
    interval values which are equal to or larger than the fastest, i.e.
    lowest, interval the particular BFD implementation supports.</t>

    <t>The proposed set of Common interval values is: 3.3msec,
    10msec, 20msec, 50msec, 100msec and 1sec.</t>

    <t>In addition support for 10sec interval together with
    multiplier values up to 255 is recommended to support
    graceful restart.</t>

    <t>The adjustment is always towards larger, i.e. slower, interval
    values when the initial interval proposed by the peer is not
    supported.</t>

    <t>This document is not adding new requirements
    with respect to how exact a timer value
    must be implemented. Supporting an interval value means to
    advertise this value in the DesiredMinTxInterval and/or
    RequiredMinRxInterval field of the BFD packets and to provide timers
    that are reasonably close.  <xref target="RFC5880" /> defines
    safety margins for the timers by defining a jitter range.</t>

    <t>How is the "Common interval set" used exactly?
    In the example above, vendor
    "A" has a fastest interval of 10msec and thus would be required to
    support all intervals in the common set that are equal or larger
    than 10msec, i.e. it would support 10msec, 20msec, 50msec, 100msec,
    1sec. Vendor "B" has a fastest interval of 20msec and thus would need to
    support 20msec, 50msec, 100msec and 1sec.
    As long as this requirement is met for the common set of values,
    then both vendor "A" and "B" are free to support additional values
    outside of the common set.</t>
    </section>

    <!-- Possibly a 'Contributors' section ... -->

    <section anchor="IANA" title="IANA Considerations">
      <t>No request to IANA.</t>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>This document does not introduce any additional security issues.</t>
    </section>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>We would like to thank Sylvain Masse and Anca Zamfir for
      bringing up the discussion about the Poll sequence, and Jeffrey Haas 
      helped finding the fine line between "exact" and "pedantic".</t>
    </section>
  </middle>

  <!--  *****BACK MATTER ***** -->

  <back>
    <!-- References split into informative and normative -->

    <references title="Normative References">
      <?rfc include="reference.RFC.2119"?>
      <?rfc include="reference.RFC.5880"?>
    </references>

    <references title="Informative References">

      <reference anchor="G.8013_Y.1731">
        <front>
          <title>ITU-T OAM functions and mechanisms for Ethernet based network
          </title>
    	  <author> <organization>ITU-T G.8013/Y.1731
                </organization> </author>
          <date month="November" year="2013" />
        </front>
      </reference>

    </references>

    <section title="Why some intervals are in the common set">
    <t>The list of common interval values is trying to balance
    various objectives. The list should not contain too many values as
    more timers may increase the implementation costs. On the other hand
    less values produces larger gaps and adjustment jumps.
    More values in the lower interval range is thus seen as critical
        to support customer needs for fast detection in setups with
        multiple vendors.

    <list style="symbols">
      <t>3.3msec: required by MPLS-TP</t>

      <t>10msec: general consensus is to support 10msec.</t>

          <t>20msec: basically avoids a larger gap in this critical
          interval region. Still allows 50-60msec detect and restore
          (with multiplier of 2) and covers existing software-based
          implementations.</t>

      <t>50msec: widely deployed interval. Supporting this value
          reflects reality of many BFD implementations today.</t>

      <t>100msec: similar to 10msec this value allows the reuse of
      <xref target="G.8013_Y.1731" /> implementations, especially
      hardware. It allows to support large scale of 9 x 100msec setups
      and would be a replacement for 3 x 300msec configurations
      used by customers to have a detection time slightly below 1sec
      for VoIP setups.</t>

      <t>1sec: as mentioned in <xref target="RFC5880" />. While the
      interval for Down packets can be 1sec or larger this draft proposes
      to use exactly 1sec to avoid interoperability issues.</t>
    </list>

        The proposed value for large intervals is 10sec, allowing for
        a timeout of 42.5 minutes with a multiplier of 255. This value
        is kept outside the common interval set as it is not required
        for normal BFD operations, which occur in the sub-second range.
        Instead the expected usage is for graceful restart, if needed.</t>
    </section>

    <section title="Timer adjustment with non-identical interval sets">
    <t><xref target="RFC5880" /> implicitly assumes that a BFD implementation
    can support any timer value equal or above the advertised value. When a
    BFD speaker starts a poll sequence then the peer must reply with the
    Final (F) bit set and adjust the transmit and detection timers
    accordingly. With contiguous software-based timers this is a valid
    assumption. Even in the case of a small number of supported
    interval values this assumption holds when both BFD speakers support
    exactly the same interval values.</t>

    <t>But what happens when both speakers support intervals that are
    not supported by the peer? An example is router "A" supporting the
    common interval set plus 200msec while router "B" support the
    common intervals plus 300msec. Assume both routers are configured
    and run at 50msec. Now router A is configured for 200msec. We know
    the result must be that both BFD speaker use 1sec timers but how
    do they reach this endpoint?
    </t>

    <t>First router A is sending a packet with 200msec. The P bit is set
    according to <xref target="RFC5880" />. The Tx timer stays at 50msec,
    the detection timer is 3 * 200msec:
    
    <list style="empty">
      <t>(A) DesiredTx: 200msec, MinimumRx: 200msec, P-bit
      <vspace blankLines="0" />
         Tx: 50msec , Detect: 3 * 200msec</t>
    </list>

    Router B now must reply with an F bit. The problem is B is
    confirming timer values which it cannot support. The only setting to
    avoid a session flap would be

    <list style="empty">
      <t>(B) DesiredTx: 300msec, MinimumRx: 300msec, F-bit
      <vspace blankLines="0" />
         Tx: 50msec , Detect: 3 * 300msec</t>
    </list>

    immediately followed by a P-bit packet as the advertised timer
    values have been changed:

    <list style="empty">
      <t>(B) DesiredTx: 300msec, MinimumRx: 300msec, P-bit
      <vspace blankLines="0" />
         Tx: 50msec , Detect: 3 * 300msec</t>
    </list>

    This is not exactly what <xref target="RFC5880" /> states in section
    6.8.7 about the transmission rate. On the other hand as we will see
    this state does not last for long.

    Router A would adjust its timers based on the received Final bit

    <list style="empty">
      <t>(A) Tx: 200msec , Detect: 3 * 1sec</t>
    </list>

    Router A is not supporting the proposed 300msec and would use
    1sec instead for the detection time.
    It would then respond to the received Poll sequence from router B,
    using 1sec as router A does not support the
    Max(200msec, 300msec):

    <list style="empty">
      <t>(A) DesiredTx: 1sec, MinimumRx: 1sec, F-bit
      <vspace blankLines="0" />
         Tx: 200msec , Detect: 3 * 1sec</t>
    </list>

    followed by its own Poll sequence as the advertised timer values
    have been changed:

    <list style="empty">
      <t>(A) DesiredTx: 1sec, MinimumRx: 1sec, P-bit
      <vspace blankLines="0" />
         Tx: 200msec , Detect: 3 * 1sec</t>
    </list>

    Router B would adjust its timers based on the received Final

    <list style="empty">
      <t>(B) Tx: 300msec , Detect: 3 * 1sec</t>
    </list>

    and would then reply to the Poll sequence from router A:

    <list style="empty">
      <t>(B) DesiredTx: 300msec, MinimumRx: 300msec, F-bit
      <vspace blankLines="0" />
         Tx: 1sec , Detect: 3 * 1sec</t>
    </list>

    which finally makes router A adjusting its timers:

    <list style="empty">
      <t>(A) Tx: 1sec , Detect: 3 * 1sec</t>
    </list>

    In other words router A and B go through multiple poll sequences
    until they reach a commonly supported interval value. Reaching such
    a value is guaranteed by this draft.</t>
    </section>
    
    <!-- Change Log
v00 2011-07-05     Initial version
    -->
  </back>
</rfc>