Internet Engineering Task Force N. Akiya
Internet-Draft M. Binderberger
Intended status: Standards Track Cisco Systems
Expires: October 27, 2012 April 25, 2012
Standardized interval support in BFD
draft-akiya-bfd-intervals-01
Abstract
This document defines a set of interval values that we call "Standard
intervals". Values of this set must be supported for transmitting
BFD control packets and for calculating the detection time in the
receive direction when the value is equal or larger than the fastest,
i.e. lowest, interval a particular BFD implementation supports.
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 27, 2012.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
Akiya & Binderberger Expires October 27, 2012 [Page 1]
Internet-Draft Standardized 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, standardized intervals . . . . . . . . . . . . . 4
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 4
6. Normative References . . . . . . . . . . . . . . . . . . . . . 5
Appendix A. Why some intervals are in the standard set . . . . . . 5
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 5
Akiya & Binderberger Expires October 27, 2012 [Page 2]
Internet-Draft Standardized 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, i.e. as long as the error in the timer interval was
small compared to 25 percent jitter.
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%
Akiya & Binderberger Expires October 27, 2012 [Page 3]
Internet-Draft Standardized interval support in BFD April 2012
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.
The example above could be 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. 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.
3. Well-defined, standardized 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 Standard interval values is: 3.3msec, 10msec,
20msec, 50msec, 300msec and 1sec.
What does "Standard interval set" 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 standard 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 standard set. As long as requirements are met for the
standard set of values, then both vendor "A" and "B" are free to
support additional values outside of the standard 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.
Akiya & Binderberger Expires October 27, 2012 [Page 4]
Internet-Draft Standardized interval support in BFD April 2012
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
(BFD)", RFC 5880, June 2010.
Appendix A. Why some intervals are in the standard set
The list of standard 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 standard set
as well as each value.
Authors' Addresses
Nobo Akiya
Cisco Systems
Email: nobo@cisco.com
Akiya & Binderberger Expires October 27, 2012 [Page 5]
Internet-Draft Standardized interval support in BFD April 2012
Marc Binderberger
Cisco Systems
Email: mbinderb@cisco.com
Akiya & Binderberger Expires October 27, 2012 [Page 6]