Network Working Group E. Salahuddin
Internet Draft J. Karthik
Expires: August 2007 Cisco Systems
February 07
Motivation for Benchmarking BFD Protocol Implementations
<draft-salahuddin-bmwg-bfd-motivation-00.txt>
Status of this Memo
By submitting this Internet-Draft, each author represents that
any applicable patent or other IPR claims of which he or she is
aware have been or will be disclosed, and any of which he or she
becomes aware will be disclosed, in accordance with Section 6 of
BCP 79.
This document may only be posted in an Internet-Draft.
Internet-Drafts are working documents of the Internet
Engineering Task Force (IETF), its areas, and its
working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Abstract
This document describes the motivation for benchmarking the
Bidirectional Forwarding Detection (BFD) protocol. The BFD protocol
is a relatively new protocol intended to detect failures in the
bidirectional path between two network elements, with potentially
very low latency [BFD, BFD-GEN]. The BFD protocol is being
implemented by several vendors and is being deployed extensively by
the service providers. Hence, it is imperative that common
understanding is established for performance and conformance
benchmarks as well as interoperability. This draft seeks to generate
Salahuddin, Karthik Expires August, 2007 [Page 1]
Internet-Draft Motivation for Benchmarking February 2007
BFD Protocol Implementations
interest on this topic in the working group. If there is sufficient
interest on this topic, drafts that address the Methodology and
Terminology for the BFD protocol could be proposed; before BMWG could
make this an official working group item.
Table of Contents
1. Introduction...................................................3
2. Existing definitions...........................................3
3. Key BFD Benchmarks.............................................4
3.1. Detection Time............................................4
3.2. Mode of operation.........................................4
3.3. Echo function capability..................................4
3.4. Control Plane Independence................................4
3.5. Minimum Rx Interval supported.............................4
3.6. Minimum Tx Interval supported.............................4
3.7. Minimum Echo Rx Time......................................4
3.8. Max number of BFD sessions supported......................4
3.9. Multi-Hop BFD sessions....................................4
3.10. Authentication Support...................................5
4. Key BFD Use Scenarios..........................................5
5. Security Considerations........................................5
6. Acknowledgements...............................................5
7. References.....................................................5
7.1. Normative References......................................5
7.2. Informative References....................................6
8. Author's Address...............................................6
Salahuddin, Karthik Expires August, 2007 [Page 2]
Internet-Draft Motivation for Benchmarking February 2007
BFD Protocol Implementations
1. Introduction
An increasingly important requirement of networking equipment is the
ability to detect a forwarding failure between two systems in order
to establish alternative paths more quickly. The BFD protocol
addresses this need by providing low-overhead and short-duration
detection of failures in the path between two network elements. Both
rapid-detection and low-overhead are open to individual
interpretation, in terms of what they entail and how to verify them.
So, it is important to establish a benchmarking framework for this
protocol.
An additional goal of the BFD protocol is to provide a single
mechanism that can be used for liveliness detection over any media,
at any protocol layer and with a wide range of detection time and
overhead. This capability makes it further necessary to have a set of
guidelines that are well understood and clearly defined to benchmark
the key attributes of the BFD protocol.
The BFD protocol is also being proposed for multi-hop virtual links
like MPLS LSPs, AToM VCs and others [BFD-MPLS, BFD-MHOP]. This is
another area which needs to be characterized and benchmarked for
comparison with the single-hop behavior of an implementation.
For reasons mentioned above, this document is being put forward to
initiate discussion on the topic and invite comments. In the process
generating enough interest that may result in future documents that
address the benchmarking needs, scenarios, procedures and terminology
of the BFD protocol.
A set of key benchmarks and use cases are also discussed in this
document.
2. Existing definitions
For the sake of clarity and continuity this RFC adopts the template
for definitions set out in Section 2 of RFC 1242. Definitions are
indexed and grouped together in sections for ease of reference.
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.
The reader is encouraged to be familiar with the commonly used BFD
terms, some of which are defined in the appendix.
Salahuddin, Karthik Expires August, 2007 [Page 3]
Internet-Draft Motivation for Benchmarking February 2007
BFD Protocol Implementations
3. Key BFD Benchmarks
3.1. Detection Time
Shortest detection time supported for a certain scale deployment.
3.2. Mode of operation
The mode of operation currently enabled on the device (Demand mode
vs. Asynchronous mode).
3.3. Echo function capability
Whether or not a device under test (DUT) can initiate and respond to
the Echo function request.
3.4. Control Plane Independence
Ability of an implementation to continue to operate when there is a
disruption in the control plane.
3.5. Minimum Rx Interval supported
This is the interval at which a DUT is capable of receiving control
messages from the BFD session peer.
3.6. Minimum Tx Interval supported
This benchmark describes the smallest interval between 2 transmitted
BFD control messages that a device is capable of supporting.
3.7. Minimum Echo Rx Time
This is the minimum interval between received BFD Echo packets that a
system is capable of supporting.
3.8. Max number of BFD sessions supported
The number of BFD sessions that can be simultaneously supported by
the DUT.
3.9. Multi-Hop BFD sessions
This benchmark verifies the capability of an implementation to
support multi-hop BFD adjacency.
Salahuddin, Karthik Expires August, 2007 [Page 4]
Internet-Draft Motivation for Benchmarking February 2007
BFD Protocol Implementations
3.10. Authentication Support
This benchmark verifies if the authentication is supported or not,
and if it is supported, what types of authentication are supported.
4. Key BFD Use Scenarios
0 AtoM VCs
1 L3VPNs
2 TE Tunnels
3 Routing Protocols
4 GRE/L2TPv3
5. Security Considerations
Documents of this type do not directly affect the security of the
Internet or of corporate networks as long as benchmarking is not
performed on devices or systems connected to operating networks.
6. Acknowledgements
We would like to acknowledge contributions from Azhar Sayeed and
Aamer Akhter. We also want to thank Jay Bromander and Rajiv Papneja
for the initial review.
7. References
7.1. Normative References
[BFD] Katz, D., and Ward, D., "Bidirectional Forwarding
Detection", draft-ietf-bfd-base-05.txt, June, 2006.
[BFD-1HOP] Katz, D., and Ward, D., "BFD for IPv4 and IPv6
(Single Hop)", draft-ietf-bfd-v4v6-1hop-05.txt,
June, 2006.
Salahuddin, Karthik Expires August, 2007 [Page 5]
Internet-Draft Motivation for Benchmarking February 2007
BFD Protocol Implementations
[BFD-GEN] Katz, D., and Ward, D., "Generic Application of
BFD, draft-ietf-bfd-v4v6-1hop-05.txt, June, 2006.
[BFD-MPLS] Aggarwal, R., and Kompella, K., "BFD for MPLS LSPs",
draft-ietf-bfd-mpls-03.txt, June, 2006.
[BFD-MHOP] D. katz, D. Ward, "BFD for Multihop Paths", draft-
ietf-bfd-multihop-04.txt
[RFC-BENCH] Bradner, S. and McQuaid, J., "Benchmarking
Methodology for Network Interconnect Devices",
RFC 2544.
7.2. Informative References
[RFC-WORDS] Bradner, S., "Key words for use in RFCs to
Indicate Requirement Levels", RFC 2119,
March 1997.
[RFC-IANA] T. Narten and H. Alvestrand, "Guidelines for
Writing an IANA Considerations Section in RFCs",
RFC 2434.
8. Author's Address
Esa Salahuddin
Cisco Systems
300 Beaver Brook Road
Boxborough, MA 01719
USA
Phone: +1 978 936 1569
Email: esa@cisco.com
Jay Karthik
Cisco Systems
300 Beaver Brook Road
Boxborough, MA 01719
USA
Phone: +1 978 936 0533
Email: jkarthik@cisco.com
Salahuddin, Karthik Expires August, 2007 [Page 6]
Internet-Draft Motivation for Benchmarking February 2007
BFD Protocol Implementations
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided
on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE
ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Salahuddin, Karthik Expires August, 2007 [Page 7]
Internet-Draft Motivation for Benchmarking February 2007
BFD Protocol Implementations
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Salahuddin, Karthik Expires August, 2007 [Page 8]