From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc4062.txt | 507 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 507 insertions(+) create mode 100644 doc/rfc/rfc4062.txt (limited to 'doc/rfc/rfc4062.txt') diff --git a/doc/rfc/rfc4062.txt b/doc/rfc/rfc4062.txt new file mode 100644 index 0000000..396c7df --- /dev/null +++ b/doc/rfc/rfc4062.txt @@ -0,0 +1,507 @@ + + + + + + +Network Working Group V. Manral +Request for Comments: 4062 SiNett Corp. +Category: Informational R. White + Cisco Systems + A. Shaikh + AT&T Labs (Research) + April 2005 + + + OSPF Benchmarking Terminology and Concepts + +Status of This Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2005). + +Abstract + + This document explains the terminology and concepts used in OSPF + benchmarking. Although some of these terms may be defined elsewhere + (and we will refer the reader to those definitions in some cases) we + include discussions concerning these terms, as they relate + specifically to the tasks involved in benchmarking the OSPF protocol. + +1. Introduction + + This document is a companion to [BENCHMARK], which describes basic + Open Shortest Path First [OSPF] testing methods. This document + explains terminology and concepts used in OSPF Testing Framework + Documents, such as [BENCHMARK]. + +2. Specification of Requirements + + 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]. + [RFC2119] key words in this document are used to ensure + methodological control, which is very important in the specification + of benchmarks. This document does not specify a network-related + protocol. + + + + + + +Manral, et al. Informational [Page 1] + +RFC 4062 OSPF Benchmarking Terminology April 2005 + + +3. Common Definitions + + Definitions in this section are well-known industry and benchmarking + terms that may be defined elsewhere. + + o White Box (Internal) Measurements + + - Definition + + White box measurements are those reported and collected on + the Device Under Test (DUT) itself. + + - Discussion + + These measurements rely on output and event recording, + along with the clocking and time stamping available on the + DUT itself. Taking measurements on the DUT may impact the + actual outcome of the test, since it can increase processor + loading, memory utilization, and timing factors. Some + devices may not have the required output readily available + for taking internal measurements. + + Note: White box measurements can be influenced by the + vendor's implementation of various timers and processing + models. Whenever possible, internal measurements should be + compared to external measurements to verify and validate + them. + + Because of the potential for variations in collection and + presentation methods across different DUTs, white box + measurements MUST NOT be used as a basis for comparison in + benchmarks. This has been a guiding principle of the + Benchmarking Methodology Working Group. + + o Black Box (External) Measurements + + - Definition + + Black box measurements infer the performance of the DUT + through observation of its communications with other + devices. + + - Discussion + + One example of a black box measurement is when a downstream + device receives complete routing information from the DUT, + it can be inferred that the DUT has transmitted all the + routing information available. External measurements of + + + +Manral, et al. Informational [Page 2] + +RFC 4062 OSPF Benchmarking Terminology April 2005 + + + internal operations may suffer in that they include not + just the protocol action times, but also propagation + delays, queuing delays, and other such factors. + + For the purposes of [BENCHMARK], external techniques are + more readily applicable. + + o Multi-device Measurements + + - Measurements assessing communications (usually in + combination with internal operations) between two or more + DUTs. Multi-device measurements may be internal or + external. + +4. Terms Defined Elsewhere + + Terms in this section are defined elsewhere and are included only as + they apply to [BENCHMARK]. + + o Point-to-Point Links + + - Definition + + See [OSPF], Section 1.2. + + - Discussion + + A point-to-point link can take less time to converge than a + broadcast link of the same speed because it does not have + the overhead of DR election. Point-to-point links can be + either numbered or unnumbered. However, in the context of + [BENCHMARK] and [OSPF], the two can be regarded as the + same. + + o Broadcast Link + + - Definition + + See [OSPF], Section 1.2. + + - Discussion + + The adjacency formation time on a broadcast link can be + greater than that on a point-to-point link of the same + speed because DR election has to take place. All routers + on a broadcast network form adjacency with the DR and BDR. + + + + + +Manral, et al. Informational [Page 3] + +RFC 4062 OSPF Benchmarking Terminology April 2005 + + + Asynchronous flooding also takes place through the DR. In + the context of convergence, it may take more time for an + LSA to be flooded from one DR-other router to another + because the LSA first has to be processed at the DR. + + o Shortest Path First Execution Time + + - Definition + + The time taken by a router to complete the SPF process, as + described in [OSPF]. + + - Discussion + + This does not include the time taken by the router to + install routes in the forwarding engine. + + Some implementations may force two intervals, the SPF hold + time and the SPF delay, between successive SPF + calculations. If an SPF hold time exists, it should be + subtracted from the total SPF execution time. If an SPF + delay exists, it should be noted in the test results. + + - Measurement Units + + The SPF time is generally measured in milliseconds. + + o Hello Interval + + - Definition + + See [OSPF], Section 7.1. + + - Discussion + + The hello interval must be the same for all routers on a + network. + + Decreasing the hello interval can allow the router dead + interval (below) to be reduced, thus reducing convergence + times in those situations where the router dead interval's + timing out causes an OSPF process to notice an adjacency + failure. Further discussion of small hello intervals is + given in [OSPF-SCALING]. + + + + + + + +Manral, et al. Informational [Page 4] + +RFC 4062 OSPF Benchmarking Terminology April 2005 + + + o Router Dead Interval + + - Definition + + See [OSPF], Section 7.1. + + - Discussion + + This is advertised in the router's Hello Packets in the + Router-DeadInterval field. The router dead interval should + be some multiple of the HelloInterval (perhaps 4 times the + hello interval) and must be the same for all routers + attached to a common network. + +5. Concepts + +5.1. The Meaning of Single Router Control Plane Convergence + + A network is termed as converged when all the devices within the + network have a loop-free path to each possible destination. However, + because we are not testing network convergence but testing + performance for a particular device within a network, this definition + needs to be streamlined to fit within a single device view. + + In this case, convergence will mean the point in time when the DUT + has performed all actions needed in order to react to the change in + the topology represented by the test condition. For instance, an + OSPF device must flood any new information it has received, rebuild + its shortest path first (SPF) tree, and install any new paths or + destinations in the local routing information base (RIB, or routing + table). + + Note that the word "convergence" has two distinct meanings: the + process of a group of individuals meeting at the same place, and the + process of an individual coming to the same place as an existing + group. This work focuses on the second meaning of the word, so we + consider the time required for a single device to adapt to a network + change to be Single Router Convergence. + + This concept does not include the time required for the control plane + of the device to transfer the information required to forward packets + to the data plane. It also does not include the amount of time + between when the data plane receives that information and when it is + able to forward traffic. + + + + + + + +Manral, et al. Informational [Page 5] + +RFC 4062 OSPF Benchmarking Terminology April 2005 + + +5.2. Measuring Convergence + + Obviously, there are several elements to convergence, even under the + definition given above for a single device, including (but not + limited to) the following: + + o The time it takes for the DUT to pass the information about a + network event on to its neighbors. + + o The time it takes for the DUT to process information about a + network event and to calculate a new Shortest Path Tree (SPT). + + o The time it takes for the DUT to make changes in its local RIB + reflecting the new shortest path tree. + +5.3. Types of Network Events + + A network event is an event that causes a change in the network + topology. + + o Link or Neighbor Device Up + + The time needed for an OSPF implementation to recognize a new + link coming up on the device, to build any necessary + adjacencies, to synchronize its database, and to perform all + other actions necessary to converge. + + o Initialization + + The time needed for an OSPF implementation to be initialized, to + recognize any links across which OSPF must run, to build any + needed adjacencies, to synchronize its database, and to perform + other actions necessary to converge. + + o Adjacency Down + + The time needed for an OSPF implementation to recognize a link + down/adjacency loss based on hello timers alone, to propagate + any information as necessary to its remaining adjacencies, and + to perform other actions necessary to converge. + + o Link Down + + The time needed for an OSPF implementation to recognize a link + down based on layer 2-provided information, to propagate any + information as needed to its remaining adjacencies, and to + perform other actions necessary to converge. + + + + +Manral, et al. Informational [Page 6] + +RFC 4062 OSPF Benchmarking Terminology April 2005 + + +6. Security Considerations + + This document does not modify the underlying security considerations + in [OSPF]. + +7. Acknowledgements + + The authors would like to thank Howard Berkowitz (hcb@clark.net), + Kevin Dubray (kdubray@juniper.net), Scott Poretsky + (sporetsky@avici.com), and Randy Bush (randy@psg.com) for their + discussion, ideas, and support. + +8. Normative References + + [BENCHMARK] Manral, V., White, R., and A. Shaikh, "Benchmarking + Basic OSPF Single Router Control Plane Convergence", + RFC 4061, April 2005. + + [OSPF] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April + 1998. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + +9. Informative References + + [OSPF-SCALING] Choudhury, Gagan L., Editor, "Prioritized Treatment of + Specific OSPF Packets and Congestion Avoidance", Work + in Progress, August 2003. + + + + + + + + + + + + + + + + + + + + + + +Manral, et al. Informational [Page 7] + +RFC 4062 OSPF Benchmarking Terminology April 2005 + + +Authors' Addresses + + Vishwas Manral, + SiNett Corp, + Ground Floor, + Embassy Icon Annexe, + 2/1, Infantry Road, + Bangalore, India + + EMail: vishwas@sinett.com + + + Russ White + Cisco Systems, Inc. + 7025 Kit Creek Rd. + Research Triangle Park, NC 27709 + + EMail: riw@cisco.com + + + Aman Shaikh + AT&T Labs (Research) + 180 Park Av, PO Box 971 + Florham Park, NJ 07932 + + EMail: ashaikh@research.att.com + + + + + + + + + + + + + + + + + + + + + + + + + +Manral, et al. Informational [Page 8] + +RFC 4062 OSPF Benchmarking Terminology April 2005 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2005). + + 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 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. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + +Manral, et al. Informational [Page 9] + -- cgit v1.2.3