Internet Engineering Task Force N. Akiya Internet-Draft M. Binderberger Intended status: Standards Track Cisco Systems Expires: October 4, 2012 April 2, 2012 Mandatory interval support in BFD draft-akiya-bfd-intervals-00 Abstract This document defines a set of interval values that must be supported for transmitting BFD control packets and for calculating the detection time in the receive direction. Implementations are allowed to define a lower limit for the interval so that only set values equal or larger than the lower limit needs to be supported. 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. Requirements Language 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 [RFC2119]. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on October 4, 2012. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. Akiya & Binderberger Expires October 4, 2012 [Page 1] Internet-Draft Mandatory interval support in BFD April 2012 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 Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. The problem with few supported intervals . . . . . . . . . . . 3 3. Well-defined intervals . . . . . . . . . . . . . . . . . . . . 4 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 6. Normative References . . . . . . . . . . . . . . . . . . . . . 4 Appendix A. Why some intervals are mandatory . . . . . . . . . . . 5 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 5 Akiya & Binderberger Expires October 4, 2012 [Page 2] Internet-Draft Mandatory interval support in BFD April 2012 1. Introduction The standard [RFC5880] describes how to calculate the transmission interval and the detection time. It does not make any statement though how so solve a situation where one BFD speaker cannot support the calculated value. In practise 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. 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 must be supported by all implementations. Details are laid out in the following sections. 2. The problem with few supported intervals Lets 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. 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. a. 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 likely is not fitting the requirements. b. System "A" could violate 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 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 Akiya & Binderberger Expires October 4, 2012 [Page 3] Internet-Draft Mandatory interval support in BFD April 2012 rate policer to protect itself and the policer would be programmed with an expectation of 20msec receive intervals. The example above could be even worse when we assume that system "B" can only support a few timer values itself. Lets assume "B" supports "20msec", "300msec" and "1sec". If both systems would adjust their advertised intervals then the adjustment ends at 1sec. 3. Well-defined intervals The problem can be reduced by defining interval values that must be supported by all implementations. Then the adjustment mechanism could find a commonly supported interval without deviating too much from the original request. The proposed set of mandatory interval values is: 3.3msec, 10msec, 20msec, 50msec, 300msec and 1sec. What does "mandatory" mean exactly? In the example above, vendor "A" has a fastest interval of 10msec and thus would be required to support all intervals in the mandatory set that are equal or larger than 10msec, i.e. it would support 10msec, 20msec, 50msec, 300msec, 1sec. Vendor "B" has a fastest interval of 20msec and thus would need to support 20msec, 50msec, 300msec and 1sec. This does not restrict both vendors from implementing additional values outside of the mandatory set. As long as requirements are met for the mandatory set of values, then both vendor "A" and "B" are free to support additional values outside of the mandatory set. 4. IANA Considerations No request to IANA. 5. Security Considerations This document does not introduce any additional security issues and the security mechanisms defined in [RFC5880] apply in this document. 6. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection Akiya & Binderberger Expires October 4, 2012 [Page 4] Internet-Draft Mandatory interval support in BFD April 2012 (BFD)", RFC 5880, June 2010. Appendix A. Why some intervals are mandatory The list of mandatory 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. Larger values in the lower interval range may be easier to support, potentially even in software instead of hardware. o 3.3msec: required by MPLS-TP o 10msec and 20msec: both values allow to detect faster than 50msec, when used with a multiplier of 2 or 3 (for 10msec). A compromise could be a single interval of 15msec. o 50msec: this seems an interval often supported by software implementations, so the assumption here is that for convenience this value should be supported. o 300msec: this would support large scale of 3 x 300msec setups used by customers to have a detection time slightly below 1sec for VoIP setups. o 1sec: as mentioned in RFC5880 With that stated, one of the primary intention of this first draft is to seek feedback on the number of interval values in the mandatory set as well as each value. Authors' Addresses Nobo Akiya Cisco Systems Email: nobo@cisco.com Marc Binderberger Cisco Systems Email: mbinderb@cisco.com Akiya & Binderberger Expires October 4, 2012 [Page 5]