Internet DRAFT - draft-ambrose-routing-protocol-term
draft-ambrose-routing-protocol-term
Nick Ambrose
Network Working Group Debby Stopp
INTERNET-DRAFT IXIA
Expires: December 2001 June 2001
Terminology for Router Protocol Testing
<draft-ambrose-routing-protocol-term-00.txt>
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]
