Nick Ambrose Network Working Group Debby Stopp INTERNET-DRAFT IXIA Expires: December 2001 June 2001 Terminology for Router Protocol Testing Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract The purpose of this draft is to describe terminology specific to the benchmarking of devices that support one or more routing protocols. It builds upon the tenets set forth in RFC 2544 and other IETF Benchmarking Methodology Working Group (BMWG) efforts. This document seeks to extend these efforts to the router benchmarking paradigm. The BMWG produces two major classes of documents: Benchmarking Terminology documents and Benchmarking Methodology documents. The Terminology documents present the benchmarks and other related terms. The Methodology documents define the procedures required to collect the benchmarks cited in the corresponding Terminology documents. Ambrose and Stopp [Page 1] INTERNET-DRAFT Terminology for Router Protocol Testing Jun. 01 Table of Contents 1. Introduction...................................................3 2. Key Words to Reflect Requirements..............................3 3. Definition Format..............................................3 3.1. Existing Terminology.........................................3 4. Table of Defined Terms.........................................4 4.1. General Nomenclature.........................................4 4.1.1. Forwarding Information Base (FIB).........................4 4.1.2. Routing Information Base (RIB)............................4 4.1.3. Route Key.................................................5 4.1.4. FIB Entry.................................................5 4.1.5. Unique FIB Entry..........................................6 4.1.6. RIB Entry.................................................6 4.1.7. Unique RIB Entry..........................................6 4.2. Specific Nomenclature........................................6 4.2.1. Peer......................................................6 4.2.2. Routing Protocol Entry....................................7 4.2.3. Routing Protocol Message..................................7 4.2.4. Routing Protocol Update Message...........................7 4.2.5. Routing Protocol Withdrawal Message.......................7 4.2.6. Advertised Routing Protocol Entry.........................8 4.2.7. Established Peer..........................................8 4.2.8. Route Packing.............................................8 4.2.9. Policy....................................................8 4.2.10. Policy Information Base...................................9 4.2.11. Route Flap................................................9 4.2.12. FIB EntryÆs Availability..................................9 4.2.13. RIB EntryÆs Availability.................................10 4.2.14. Capacity.................................................10 4.2.15. Performance..............................................11 4.2.16. Routing Protocol Entries accepted rate...................11 4.2.17. PeerÆs offered rate......................................12 4.2.18. PeerÆs accepted rate.....................................12 4.2.19. Convergence..............................................13 5. Security Considerations.......................................13 6. References....................................................14 7. Author's Addresses............................................14 Ambrose and Stopp [Page 2] INTERNET-DRAFT Terminology for Router Protocol Testing Jun. 01 1. Introduction 2. Key Words to Reflect 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. 3. Definition Format This section cites the template suggested by RFC 1242 in the specification of a term to be defined. Term to be defined. Definition: The specific definition for the term. Discussion: A brief discussion of the term, its application, or other information that would build understanding. Measurement units: Units used to record measurements of this term, if applicable. [Issues:] List of issues or conditions that affect this term. This field can present items the may impact the term's related methodology or otherwise restrict its measurement procedures. This field is optional in this document. [See Also:] List of other terms that are relevant to the discussion of this term. This field is optional in this document. 3.1. Existing Terminology This document draws on existing terminology defined in other BMWG work. Examples include, but are not limited to: Device Under Test (DUT) [RFC 2285, section 3.1.1] System Under Test (SUT) [RFC 2285, section 3.1.2] Note: "DUT/SUT" refers to a metric that may be applicable to a DUT or SUT. Ambrose and Stopp [Page 3] INTERNET-DRAFT Terminology for Router Protocol Testing Jun. 01 4. Table of Defined Terms 4.1. General Nomenclature 4.1.1. Forwarding Information Base (FIB) Definition: ôThe table containing the information necessary to forward Datagrams. At minimum, this contains the interface identifier and next hop information for each Route.ö[4] Discussion: This is a generalization of the FIB concept defined in [4]. The concept of a FIB is extended to support IPV6 and forwarding of frames based on information other than IP addresses (e.g. MPLS label). When we take performance measurements at the Data Plane, we are measuring the performance of the FIB of a particular DUT/SUT. 4.1.2. Routing Information Base (RIB) Definition: The table that contains all destinations to which the DUT may forward frames. Discussion: Entries in the RIB can be used to populate the FIB based on some selection criteria. These entries can also be used as a source to re-advertise information. It is quite common for the RIB to contain multiple paths to the same destination (possibly with the same or different degree of preference and possibly advertised from multiple sources). The RIB can also be used to generate information to re-advertise. When we take performance measurements at the Control Plane, we are measuring performance of the RIB (capacity, rates of acceptance etc.) See Also: FIB Ambrose and Stopp [Page 4] INTERNET-DRAFT Terminology for Router Protocol Testing Jun. 01 4.1.3. Route Key Definition: A data item used to identify a path in a network Discussion: A Route Key is a Protocol Specific data item that can be used as a key or partial key for lookup in a FIB or RIB. (i.e. an IP Route Key could be a CIDR Prefix, for MPLS, a pair(incoming interface, label) ). When used in a RIB, it MAY represent a network path that is not available for forwarding of frames. When used in a FIB, it represents a network path that is available for forwarding frames. This is a generalization of the term ôPrefixö defined in [4] which is intended to extend beyond pure IP routing (e.g. MPLS networks) See Also: RIB FIB 4.1.4. FIB Entry Definition: An entry in a FIB consisting of at least a Pair(Route Key, Next Hop) Discussion: A FIB Entry contains enough information to allow for forwarding of frames. The Route key determines which incoming frames match this entry and the Next Hop governs which interface the frames will be forwarded and can potentially include information that modifies the frame contents (e.g. MPLS label swapping). Next Hop is Routing Protocol Specific (i.e. for IP a Next Hop could be an IP Address, for MPLS, a pair (outgoing interface, outgoing label). This is intended as a generalization of an ôIP Routeö See Also: FIB RIB Rib Entry Ambrose and Stopp [Page 5] INTERNET-DRAFT Terminology for Router Protocol Testing Jun. 01 4.1.5. Unique FIB Entry Definition: A FIB Entry such that, for a given FIB, there is only one match to the Route Key. See Also: FIB Entry 4.1.6. RIB Entry Definition: An entry in a RIB consisting of at least a Pair(Route Key, Attributes). Discussion: A Protocol-specific data item that associates certain attributes (i.e. degree of preference, Community) with a Route Key. 4.1.7. Unique RIB Entry Definition: A RIB Entry such that for a given RIB, there is only one match to the Route Key Discussion: See Also: FIB Entry 4.2. Specific Nomenclature 4.2.1. Peer Definition: Two entities are Peers for a given Routing Protocol if they have established communication via that Protocol. Discussion: Ambrose and Stopp [Page 6] INTERNET-DRAFT Terminology for Router Protocol Testing Jun. 01 4.2.2. Routing Protocol Entry Definition: A pair consisting of at least (Route Key, Attributes) Discussion: Attributes are Protocol-specific (i.e. Next Hop, Community etc.) An advertised Routing Protocol Entry may cause a DUT to install a new RIB Entry into its RIB (with a potentially different set of Attributes than those advertised). 4.2.3. Routing Protocol Message Definition: A message containing Protocol-specific information, exchanged between Peers. Discussion: Some messages are used for initiation (i.e. BGP OPEN, OSPF HELLO) whereas some are used to advertise or withdraw information (BGP UPDATE, OSPF LSA packets). 4.2.4. Routing Protocol Update Message Definition: A Routing Protocol Message that advertises Routing Protocol Entries to a Peer. Discussion: Note: Each Update message MAY advertise multiple Routing Protocol Entries to a Peer 4.2.5. Routing Protocol Withdrawal Message Definition: A Routing Protocol Message that removes Routing Protocol Entries from a Peer Discussion: Ambrose and Stopp [Page 7] INTERNET-DRAFT Terminology for Router Protocol Testing Jun. 01 Note: Each Withdrawal message may remove multiple Routing Protocol Entries from a Peer 4.2.6. Advertised Routing Protocol Entry Definition: A Routing Protocol Entry that has last been sent to a DUT/SUT in a Routing Protocol Update Message Discussion: See Also: Routing Protocol Entry Routing Protocol Update Message 4.2.7. Established Peer Definition: A peer that is in a state where it can accept Routing Protocol Update or withdrawal messages. Discussion: A Peer may have a number of states. Some of these states may be used for initiation (e.g. OSPF HELLO's, BGP OPEN) during which the protocol may not be capable of exchanging routing information. 4.2.8. Route Packing Definition: Number of Routing Protocol Entries that exist in a single Routing Protocol Update or Withdraw Message. Discussion: Certain protocols such as BGP, support this concept (i.e. a single BGP UPDATE message can advertise multiple NLRI entries with common attributes). This can affect convergence and performance metrics. Protocols that do not support such a concept implicitly have a Route Packing of 1. 4.2.9. Policy Definition: Policy is ôthe ability to define conditions for accepting, rejecting and modifying Routing Protocol Entries received in Routing Protocol Update Messagesö. Ambrose and Stopp [Page 8] INTERNET-DRAFT Terminology for Router Protocol Testing Jun. 01 Discussion: Some Routing Protocols do not explicitly support policy (e.g. OSPF) such Protocols can be viewed as having ôImplicit Policiesö û i.e. OSPF has an implicit policy of Accept(All), Re-advertise(All). 4.2.10. Policy Information Base Definition: A collection of policies that are applied to incoming or outgoing Routing Entries. Discussion: Policy can be applied to incoming Routing Protocol Entries before they are added to the RIB, or to RIB entries before they are re- advertised. 4.2.11. Route Flap Definition: The withdrawing of a currently advertised Routing Protocol Entry or the advertise and withdrawal of a currently unadvertised Routing Protocol Entry. Discussion: A route flap is either an existing Routing Protocol Entry disappearing (either being explicitly withdrawn, or being deleted due to a peer closing) or a Routing Protocol Entry being advertised and then disappearing. 4.2.12. FIB EntryÆs Availability Definition: The time at which a RIB Entry has been installed in a RIB/FIB and can be re-advertised or can be used to forward frames. Discussion: A FIB Entry is available as soon as it is stored in the FIB (and so is available to forward frames) Ambrose and Stopp [Page 9] INTERNET-DRAFT Terminology for Router Protocol Testing Jun. 01 4.2.13. RIB EntryÆs Availability The time at which a RIB Entry has been installed in a RIB and is available to be re-advertised. Discussion: A RIB Entry may be available but not re-advertised if it is not the best route to itÆs destination. Issues: It is very difficult to measure these timings, since they are events internal to a DUT. In this case, we measure an externally visible event as an approximation (i.e. for Control plane, we can measure the re-advertisement of a Protocol Route Entry, for Control plane, the receipt of a Data frame addressed to the Protocol Route Entries Route Key) 4.2.14. Capacity This section defines metrics used to measure the capacity of a DUT/SUT to establish peers and accept Routing Protocol Entries. This is a 2-dimentional metric, which can be measured at either the control plane or data plane. The sections below break this into two metrics (Peer capacity and Route capacity) but it is useful to measure as ôPeer capacity at a given number of RIB Entries.ö 4.2.14.1. Peer Capacity Definition: Number of peers a DUT can establish with zero Routing Protocol Entries Discussion: Issues: Certain Protocols may require advertising at least one Routing Protocol Entry (i.e. a Link-state protocol might require advertising at least one Routing Protocol Entry (e.g. to represent at least one interface). 4.2.14.2. Route Capacity Definition: Ambrose and Stopp [Page 10] INTERNET-DRAFT Terminology for Router Protocol Testing Jun. 01 Number of Routing Protocol Entries that can be accepted from a single peer. Discussion: When measuring at the control plane, we verify the number of Routing Protocol Entries re-advertised by the DUT/SUT. When measuring at the data plane, we measure that the DUT/SUT is able to forward at least one frame addressed to each Route Key in each Routing Protocol Entry advertised. Issues: Measuring at the control plane and data plane can often produce different capacities as DUT/SUTÆs FIB resources may be more limited than their RIBÆs as they are often implemented in hardware. 4.2.15. Performance 4.2.15.1. Routing Protocol Entries offered rate Definition: Rate at which a test device is capable of advertising Routing Protocol Entries. Discussion: This measures how quickly a test device is able to advertise Routing Protocol Entries to a DUT. It is important to measure this quantity as the DUT may be able to accept Routing Protocol Entries more quickly than the tester can advertise. Issues: Units: RIB Routing Protocol Entries/sec 4.2.16. Routing Protocol Entries accepted rate Definition: Rate at which a DUT is able to accept/withdraw Routing Protocol Entries. Ambrose and Stopp [Page 11] INTERNET-DRAFT Terminology for Router Protocol Testing Jun. 01 Discussion: This measures the rate at which a DUT is able to accept Routing Protocol Entries in Routing Protocol Update or Withdraw messages and insert or remove the corresponding RIB Entries from its RIB. Issues: This is a metric that is internal to a DUT and must usually be measured indirectly. A RIB Entry is accepted when it is available into the RIB. We can measure the Routing Protocol Entries offered rate from the tester to the DUT and then verify that the DUT is able to re- advertise all offered Routing Protocol Entries. Units: Routing Protocol Entries/sec 4.2.17. PeerÆs offered rate Definition: Rate of peer establish/teardown attempts that a test device can generate. Discussion: It is important to measure this quantity, as the DUT may be able to establish Peers more quickly than the test device. Issues: Units: Number of PeerÆs/sec 4.2.18. PeerÆs accepted rate Definition: Rate a DUT is able to accept or tear-down peerÆs. Discussion This measures how quickly a DUT can establish peers. Ambrose and Stopp [Page 12] INTERNET-DRAFT Terminology for Router Protocol Testing Jun. 01 Issues: This is a metric that is internal to a DUT, in order to measure it, we can measure how many peers the test device can establish after a given amount of time. This introduces the possibility that some peers have timed out on the DUT but the test device has not yet noticed this. In order to reduce this possibility, it is important that the test measure the time the last peer was offered, but then continues to run until all peerÆs keepalive timers have had a chance to expire and then verify that all peers are actually established. This could also be verified using a SNMP query to the DUT. Units: Number of peerÆs rate 4.2.19. Convergence 4.2.19.1. Route convergence Definition: The delay from the offering of a Routing Protocol Entry until the Routing Protocol Entry is available at the DUT. Discussion: Issues: Units: Time in seconds. 5. Security Considerations As this document is solely for the purpose of providing metric methodology and describes neither a protocol nor a protocol's implementation, there are no security considerations associated with this document. Methodologies regarding the collection of the metrics described within this document may need to cite security considerations. This document does not address methodological issues. Ambrose and Stopp [Page 13] INTERNET-DRAFT Terminology for Router Protocol Testing Jun. 01 6. References [1] Bradner, S., "Benchmarking Terminology for Network Interconnection Devices", RFC 1242, July 1991. [2] Bradner, S., and J. McQuaid, "Benchmarking Methodology for Network Interconnect Devices", RFC 2544, March 1999. [3] Bradner, S. "Use of Keywords in RFCs to Reflect Requirement Levels, RFC 2119, March 1997 [4] Baker, F., ôRequirements for IP Version 4 routersö, RFC 1812, June 1995 7. Author's Addresses Nick Ambrose IXIA 26601 W. Agoura Rd. Calabasas, CA 91302 USA Phone: 818 871 1800 EMail: nick@ixiacom.com Debby Stopp IXIA 26601 W. Agoura Rd. Calabasas, CA 91302 USA Phone: 818 871 1800 EMail: debby@ixiacom.com Ambrose and Stopp [Page 14]