Network Working Group S. Poretsky Internet Draft Allot CommunicationsExpires: September 08, 2009Intended Status: Informational Brent Imhoff Juniper Networks~~October 15, 2008~~March 08, 2009Terminology for Benchmarking Link-State IGP Data Plane Route Convergence~~<draft-ietf-bmwg-igp-dataplane-conv-term-16.txt> Intellectual Property Rights (IPR) statement: By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims~~<draft-ietf-bmwg-igp-dataplane-conv-term-17.txt> Statusof~~which he or she~~this Memo This Internet-Draftis~~aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed,~~submitted to IETFin~~accordance~~full conformancewith~~Section 6~~the provisionsof BCP78 and BCP79.~~Status of this Memo~~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.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.This Internet-Draft will expire on September 8, 2009.Copyright Notice Copyright~~(C) The~~(c) 2009IETF Trust~~(2008).~~and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.ABSTRACT This document describes the terminology for benchmarking Interior Gateway Protocol (IGP) Route Convergence. The terminology is to be used for benchmarking IGP convergence time through externally observable (black box) data plane measurements. The terminology can be applied to any link-state IGP, such as ISIS and OSPF. Link-State IGP Data Plane Route Convergence Table of Contents 1. Introduction~~.................................................2~~and Scope........................................32. Existing~~definitions .........................................3~~Definitions .........................................43. Term~~definitions..............................................4~~Definitions..............................................43.1~~Convergence Event.........................................4 3.2~~States 3.1.1Route~~Convergence.........................................4 3.3~~Convergence....................................4 3.1.2Full~~Convergence..........................................5 3.4~~Convergence.....................................5 3.1.3Network~~Convergence.......................................5 3.5~~Convergence..................................5 3.1.4Route-Specific~~Convergence................................6 3.6 Packet Loss...............................................7 3.7~~Convergence...........................6 3.1.5 Stale Forwarding.....................................6 3.2 Events 3.2.1Convergence~~Packet Loss...................................7 3.8~~Event....................................7 3.2.2Convergence Event~~Instant.................................8 3.9~~Trigger............................7 3.2.3 Convergence Event Instant............................8 3.2.4Convergence Recovery~~Instant..............................8 3.10~~Instant.........................8 3.2.5First Route Convergence~~Instant..........................9 3.11~~Instant......................9 3.2.6Convergence Event~~Transition.............................9 3.12~~Transition.........................9 3.2.7Convergence Recovery~~Transition..........................10 3.13~~Transition......................10 3.2.8 Nested Convergence Events............................10 3.3 Interfaces 3.3.1 Local Interface......................................11 3.3.2 Neighbor Interface...................................11 3.3.3 Remote Interface.....................................11 3.3.4 Preferred Egress Interface...........................12 3.3.5 Next-Best Egress Interface...........................12 3.4 Benchmarking Method 3.4.1 Packet Loss..........................................13 3.4.2 Convergence Packet Loss..............................13 3.4.3Rate-Derived Convergence~~Time............................10 3.14~~Method......................14 3.4.4Loss-Derived Convergence~~Time............................11 3.15~~Method......................14 3.4.5 Packet Sampling Interval.............................15 3.5 Benchmarks 3.5.1 Full Convergence Time................................17 3.5.2 First Route Convergence Time.........................17 3.5.3Route-Specific Convergence~~Time..........................12 3.16~~Time......................17 3.5.4Sustained Convergence Validation~~Time....................13 3.17 First Route Convergence Time.............................14 3.18~~Time................18 3.5.5Reversion Convergence~~Time...............................15 3.19 Packet Sampling Interval.................................15 3.20 Local Interface..........................................16 3.21 Neighbor Interface.......................................16 3.22 Remote Interface.........................................17 3.23 Preferred Egress Interface...............................17 3.24 Next-Best Egress Interface...............................17 3.25 Stale Forwarding.........................................18 3.26 Nested Convergence Events................................18~~Time...........................194. IANA Considerations...........................................19 5. Security Considerations.......................................19 6.~~Acknowledgements..............................................19~~Acknowledgements..............................................207.~~References....................................................19~~References....................................................208. Author's~~Address..............................................20~~Address..............................................21 Link-State IGP Data Plane Route Convergence1. Introductionand ScopeThis draft describes the terminology for benchmarking Interior Gateway Protocol (IGP) Route Convergence. The motivation and applicability for this benchmarking is provided in [Po07a]. The methodology to be used for this benchmarking is described in [Po07m]. Thepurpose of this document is to introduce new terms required to complete execution of the IGP Route Convergence Methodology [Po07m]. These terms apply to IPv4 and IPv6 traffic and IGPs. Convergence times are measured at the Tester on the data plane by observing packet loss through the DUT. Themethodology and terminology to be used for benchmarking Route Convergence can be applied to any link-state IGP such as ISIS [Ca90] and OSPF [Mo98]. The data plane is measured to obtain black-box (externally observable) convergence benchmarking metrics.~~The purpose of this document~~When thereis~~to introduce new terms required to complete execution of~~no packer loss observed inthe~~IGP Route Convergence Methodology [Po07m]. These terms apply to IPv4 and IPv6 traffic and IGPs. Link-State IGP Data Plane Route Convergence~~data plane, the convergence time SHALL be reported as zero.An example of Route Convergence as observed and measured from the data plane is shown in Figure 1. The graph in Figure 1 shows Forwarding Rate versus Time. Time 0 on the X-axis is on the far right of the graph. The Offered Load to the ingress interface of the DUT SHOULD equal the measured~~maximum~~Throughput [Ba99][Ma98] of the DUT and the Forwarding Rate [Ma98]and Convergence Packet Lossis measured at the~~egress~~Preferred and Next-Best Egressinterfaces of the~~DUT. The~~DUT befire, during, and after a Convergence Event Trigger. Thesecomponents of the graph~~and the metrics~~are defined in the Term Definitions section. Full~~Convergence,~~Convergence->Convergence Convergence Recovery EventEvent Time=Instant Instant~~Time =~~Trigger0sec Forwarding~~Rate =~~Rate= ^^ ^ ^ Offered~~Load =~~Load=Offered Load --> ------\ Packet~~/-------- <---Max~~/----------- <--MaxThroughput \ Loss /<----Convergence Convergence------->\ / Event Transition Recovery Transition \ / \_____/<------Maximum Packet Loss ^ First Route Convergence Instant Y-axis = Forwarding Rate X-axis = Time (increases right to left to match commercial test equipment displays) Figure 1. Convergence GraphLink-State IGP Data Plane Route Convergence2. Existing~~definitions~~DefinitionsThis document uses existing terminology defined in other BMWG work. Examples include, but are not limited to: Latency [Ref.[Ba91], section 3.8] Frame Loss Rate [Ref.[Ba91], section 3.6] Throughput [Ref.[Ba91], section 3.17] Device Under Test (DUT) [Ref.[Ma98], section 3.1.1] System Under Test (SUT) [Ref.[Ma98], section 3.1.2] Out-of-order Packet [Ref.[Po06], section 3.3.2] Duplicate Packet [Ref.[Po06], section 3.3.3] Packet Reordering [Ref.[Mo06], section 3.3] 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 BCP 14, RFC 2119 [Br97]. RFC 2119 defines the use of these key words to help make the intent of standards track documents as clear as possible. While this document uses these keywords, this document is not a standards track document.~~Link-State IGP Data Plane Route Convergence~~3. Term Definitions 3.1~~Convergence Event Definition: The occurrence of a planned or unplanned event in the network that results in a change in the egress interface of the Device Under Test (DUT) for routed packets. Discussion: Convergence Events include link loss, routing protocol session loss, router failure, configuration change, and better next-hop learned via a routing protocol. Measurement Units: N/A Issues: None See Also: Convergence Packet Loss Convergence Event Instant 3.2~~States 3.1.1Route Convergence Definition: The action to update all components of the router with the most recent route change(s) including the Routing Information Base (RIB) and Forwarding Information Base (FIB), along with software and hardware tables, such that forwarding is successful for one or more route entries. Discussion: Route Convergence MUST occur after a Convergence Event. Route Convergence can be observed externally by the rerouting of data traffic to the Next-best Egress Interface. Also, completion of Route Convergence may or may not be sustained over time. Measurement Units: N/A Issues: None See Also: Network Convergence Full Convergence Convergence Event Link-State IGP Data Plane Route Convergence~~3.3~~3.1.2Full Convergence Definition: Route Convergence for an entire FIB in which complete recovery from the Convergence Event is indicated by the DUT~~Throughput~~throughputequal to the offered load. Discussion: When benchmarking convergence, it is useful to measure the time to converge an entire FIB. For example, a Convergence Event can be produced for an OSPF table of 5000 routes so that the time to converge routes 1 through 5000 is measured. Completion of Full Convergence is externally observable from the data plane when the Throughput of the data plane traffic on the Next-Best Egress Interface equals the offered load. Full~~convergence~~ConvergenceMAY be measured using Rate-Derived Convergence~~Time (3.13)~~Methodor calculated using Loss-Derived Convergence~~Time (3.14). When performing Route-Specific Convergence (3.5) measurements, Full Convergence may be obtained by measuring the maximum Route Specific Convergence Time (3.15).~~Method.Full Convergence may or may not be sustained over time. The Sustained Convergence Validation Time~~(3.16)~~MUST be applied. Measurement Units: N/A Issues: None See Also: Network Convergence Route Convergence Convergence Event~~3.4~~3.1.3Network Convergence Definition: The process of updating of all routing tables, including distributed FIBs, in all routers throughout the network. Discussion: Network Convergence requires completion of all Route Convergence operations for all routers in the network following a Convergence Event. Completion of Network Convergence can be observed by recovery of System Under Test (SUT) Throughput to equal the offered load, with no Stale Forwarding, and no Blenders [Ca01][Ci03].Measurement Units: N/A Issues: NoneLink-State IGP Data Plane Route Convergence~~Measurement Units: N/A Issues: None~~See Also: Route Convergence Stale Forwarding~~3.5~~3.1.4Route-Specific Convergence Definition: Route Convergence for one or more specific route entries in the FIB in which recovery from the Convergence Event is indicated~~by~~whendata-plane traffic for~~a~~theflow [Po06] matching that route entry(ies)~~being~~isrouted to the Next-Best Egress Interface. Discussion: When benchmarking convergence, it is sometimes useful to measure the time to converge a single flow [Po06] or group of flows to benchmark convergence time for one or a few route entries in the FIB instead of the entire FIB. Route-Specific Convergence of a flow is externally observable from the data plane when the data plane traffic for that flow is routed to the Next-Best Egress Interface. Measurement Units: N/A Issues: None See Also: Full Convergence Route Convergence Convergence Event3.1.5 Stale Forwarding Definition: Forwarding of traffic to route entries that no longer exist or to route entries with next-hops that are no longer preferred. Discussion: Stale Forwarding can be caused by a Convergence Event and can manifest as a "black-hole" or microloop that produces packet loss. Stale Forwarding can exist until Network Convergence is completed. Stale Forwarding cannot be observed with a single DUT. Measurement Units: N/A Issues: None See Also: Network ConvergenceLink-State IGP Data Plane Route Convergence~~3.6 Packet Loss~~3.2 Events 3.2.1 Convergence EventDefinition: The~~number~~occurrenceof~~packets that should have been forwarded by a DUT under~~a~~constant offered load~~planned or unplanned event in the networkthat~~were not forwarded due to lack of resources. Discussion: Packet Loss is~~results ina~~modified version~~change in the egress interfaceof the~~term "Frame Loss Rate" as defined in [Ba91]. The term "Frame Loss" is intended for Ethernet Frames while "Packet Loss" is intended~~Device Under Test (DUT)for~~IP~~routedpackets.~~Packet Loss can be measured as~~Discussion: Convergence Events include link loss, routing protocol session loss, router failure, configuration change, and better next-hop learned viaa~~reduction in forwarded traffic from the Throughput [Ba91] of the DUT.~~routing protocol.Measurement~~units: Number of offered packets that are not forwarded.~~Units: N/AIssues: None See Also: Convergence Packet Loss~~3.7~~Convergence~~Packet Loss~~Event Instant 3.2.2 Convergence Event TriggerDefinition:~~The number of packets lost due~~An action taken by the Testertoproducea Convergence~~Event until Full Convergence completes.~~Event.Discussion:~~Convergence Packet Loss includes packets that were lost and packets that were delayed due to buffering.~~The Convergence~~Packet Loss observed in a Packet Sampling Interval may or~~Event Trigger is introduced by the Tester andmay~~not~~be~~equal to the number of packets in the offered load during the interval following~~indicated by link loss, routing protocol session loss, router failure, configuration change, ora~~Convergence Event (see Figure 1).~~better next-hop learned via a routing protocol introduced by the Tester.Measurement Units:~~number of packets~~N/AIssues: None See Also:~~Packet Loss Route Convergence~~Convergence EventConvergencePacket~~Sampling Interval~~Loss Convergence Recovery InstantLink-State IGP Data Plane Route Convergence~~3.8~~3.2.3Convergence Event Instant Definition: The time instant that a Convergence Event becomes observable in the data plane. Discussion: Convergence Event Instant is observable from the data plane as the precise time that the device under test begins to exhibit packet loss.The Convergence Event Instant is produced by the Convergence Event Trigger. The Convergence Event Instant always occurs concurrent or subsequent to the Tester introducing the Convergence Event Trigger.Measurement Units: hh:mm:ss:nnn:uuu, where 'nnn' is milliseconds and 'uuu' is microseconds. Issues: None See Also: Convergence Event Convergence Packet Loss Convergence Recovery Instant~~3.9~~3.2.4Convergence Recovery Instant Definition: The time instant that Full Convergence completion is~~measured and then maintained for an interval of duration equal to the Sustained Convergence Validation Time.~~observed.Discussion: Convergence Recovery Instant is measurable from the data plane as the precise time that the device under test completes Full Convergence.The Convergence Recovery Instant MUST be maintained for an interval of duration equal to the Sustained Convergence Validation Time.Measurement Units: hh:mm:ss:nnn:uuu, where 'nnn' is milliseconds and 'uuu' is microseconds. Issues: None See Also: Sustained Convergence Validation Time Convergence Packet Loss Convergence Event Instant Link-State IGP Data Plane Route Convergence~~3.10~~3.2.5First Route Convergence Instant Definition: The time instant a first route entry has converged following a Convergence Event, as observed by receipt of the first packet from the Next-Best Egress Interface. Discussion: The First Route Convergence Instant is an indication that the process to achieve Full Convergence has begun. Any route may be the first to converge for First Route Convergence Instant. Measurement on the data-plane enables the First Route Convergence Instant to be observed without any white-box information from the DUT. Measurement Units:~~N/A~~hh:mm:ss:nnn:uuu, where 'nnn' is milliseconds and 'uuu' is microseconds.Issues: None See Also: Route Convergence Full Convergence Stale Forwarding~~3.11~~3.2.6Convergence Event Transition Definition: A time interval observed following a Convergence Event in which Throughput gradually reduces to a minimum value. Discussion: The Convergence Event Transition is best observed for Full Convergence. The egress packet rate observed during a Convergence Event Transition may not decrease linearly and may not decrease to zero. Both the offered load and the Packet Sampling Interval influence the observations of the Convergence Event Transition. For example,~~even~~it is possible thatif the Convergence Event were to cause the Throughput [Ba91] to drop to zero~~there would~~then this may notbe~~some number of packets observed, unless~~observed ifthe Packet Sampling Interval is~~exactly aligned with the Convergence Event.~~set too high.This is further discussed with the term "Packet Sampling Interval". Measurement Units: seconds Issues: NoneLink-State IGP Data Plane Route ConvergenceSee Also: Convergence Event Full Convergence Packet Sampling Interval~~Link-State IGP Data Plane Route Convergence 3.12~~3.2.7Convergence Recovery Transition Definition: The characteristic of the DUT in which Throughput gradually increases to equal the offered load. Discussion: The Convergence Recovery Transition is best observed for Full Convergence. The egress packet rate observed during a Convergence Recovery Transition may not increase linearly. Both the offered load and the Packet Sampling Interval influence the observations of the Convergence Recovery Transition. This is further discussed with the term "Packet Sampling Interval". Measurement Units: seconds Issues: None See Also: Full Convergence Packet Sampling Interval~~3.13 Rate-Derived~~3.2.8 NestedConvergence~~Time~~EventsDefinition: The~~amount of time for Convergence Packet Loss to persist upon~~occurrence of a Convergence Event~~until Full Convergence has completed. Rate-Derived Convergence Time can be measured as~~whilethe~~time difference~~route table is convergingfrom~~the Convergence Event Instant to the Convergence Recovery Instant, as shown with Equation 1. (Equation 1) Rate-Derived~~a priorConvergence~~Time =~~Event. Discussion: TheConvergence~~Recovery Instant -~~Events for a NestedConvergence Event~~Instant. Discussion: Rate-Derived~~MUST occur with different neighbors. A common observation from a NestedConvergence~~Time SHOULD~~Event willbe~~measured at~~the~~maximum Throughput~~withdrawalof~~the DUT. At least~~routes fromone~~packet per route in~~neighbor whilethe~~FIB for all~~routes~~in the FIB MUST be offered to the DUT within the Packet Sampling Interval. Failure to achieve Full Convergence results in a Rate-Derived Convergence Time benchmark~~of~~infinity. It is RECOMMENDED that the Rate-Derived~~another neighbor are being installed. Measurement Units: N/A Issues: None See Also:Convergence~~Time be measured when benchmarking Full Convergence.~~EventLink-State IGP Data Plane Route Convergence3.3 Interfaces 3.3.1 Local Interface Definition: An interface on the DUT. Discussion: A failure of the Local Interface indicates that the failure occurred directly on the DUT.Measurement Units:~~seconds~~N/AIssues: None See Also:~~Convergence Packet Loss Convergence Recovery Instant Convergence Event Instant Full Convergence 3.14 Loss-Derived Convergence Time~~Neighbor Interface Remote Interface 3.3.2 Neighbor InterfaceDefinition: The~~amount of time it takes for Full Convergence~~interface on the neighbor router or tester that is directly linkedto~~be completed as calculated from~~the~~amount~~DUT's Local Interface. Discussion: A failureof~~Convergence Packet Loss. Loss-Derived Convergence Time can be calculated from Convergence Packet Loss as shown with Equation 2. Equation 2 - Loss-Derived Convergence Time = Convergence Packets Loss / Offered Load where units are packets / packets/second = seconds Discussion: Optimally, the Convergence Event Transition and Convergence Recovery Transition are instantaneous so~~a Neighbor Interface indicatesthat~~the Rate-Derived Convergence Time = Loss-Derived Convergence Time. However, router implementations are less than ideal. Loss-Derived Convergence Time gives~~a~~better than actual result when converging many routes simultaneously because it ignores the Convergence Recovery Transition. Rate-Derived Convergence Time takes the Convergence Recovery Transition into account. Equation 2 calculates~~failure occurred on a neighbor router's interface that directly linksthe~~average convergence time over all routes~~neighbor routerto~~which packets have been sent. Since this average convergence time is in general smaller than~~the~~maximum convergence time over all routes, Loss-Derived Convergence Time~~DUT. Measurement Units: N/A Issues: None See Also: Local Interface Remote Interface 3.3.3 Remote Interface Definition: An interface on a neighboring router thatis not~~the preferred metric~~directly connectedto~~indicate Full Convergence completion. For this reason~~any interface onthe~~RECOMMENDED benchmark metric for Full Convergence~~DUT. Discussion: A failure of a Remote Interface indicates that the failure occurred on a neighbor router's interface thatisnot directly connected tothe~~Rate-Derived Convergence Time.~~DUT.Link-State IGP Data Plane Route Convergence~~Guidelines for reporting Loss-Derived Convergence Time are provided in [Po07m].~~Measurement Units:~~seconds~~N/AIssues: None See Also:~~Convergence Event Convergence Packet Loss Rate-Derived Convergence Time Route-Specific Convergence Convergence Event Transition Convergence Recovery Transition 3.15 Route-Specific Convergence Time~~Local Interface Neighbor Interface 3.3.4 Preferred Egress InterfaceDefinition: The~~amount of time it takes~~outbound interface from the DUTfor~~Route-Specific Convergence~~traffic routedto~~be completed as calculated from~~the~~amount of Convergence Packet Loss per flow. Route-Specific Convergence Time can be calculated from Convergence Packet Loss as shown with Equation 3. Equation 3 - Route-Specific Convergence Time = Convergence Packets Loss / Offered Load where units are packets / packets/second = seconds~~preferred next-hop.Discussion:~~It~~The Preferred Egress Interfaceis~~possible to provide an offered load that has flows matching every route entry in~~the~~FIB and benchmarking Route-Specific~~egress interface prior to aConvergence~~Time for all route entries.~~Event. Measurement Units: N/A Issues: None See Also: Next-Best Egress Interface 3.3.5 Next-Best Egress Interface Definition:The~~number of flows that can be measured is dependent upon the flow measurement capabilities of~~outbound interface fromthe~~Tester. When benchmarking Route-Specific Convergence, Convergence Packet Loss is measured for specific flow(s) and Equation 3 is applied~~DUTfor~~each flow. Each flow has a single destination address matching a different route entry. The fastest measurable convergence time is equal~~traffic routedto the~~time between two consecutive packets of a flow offered by~~second-best next-hop. It isthe~~Tester. The Route-Specific Convergence Time benchmarks enable minimum, maximum, average,~~same media typeand~~median convergence time measurements to be reported by comparing~~link speed asthe~~results for~~Preferred Egress Interface Discussion: The Next-Best Egress Interface becomesthe~~different route~~egress interface after a Convergence Event. Measurement Units: N/A Issues: None See Also: Preferred Egress InterfaceLink-State IGP Data Plane Route Convergence~~entries. It also enables benchmarking~~3.4 Benchmarking Methods 3.4.1 Packet Loss Definition: The numberof~~convergence time when configuring~~packets that should have been forwarded bya~~priority value for route entry(ies). Since multiple Route-Specific Convergence Times can be measured it is possible~~DUT under a constant offered load that were not forwarded dueto~~have an array~~lackof~~results.~~resources. Discussion: Packet Loss is a modified version of the term "Frame Loss Rate" as defined in [Ba91].The~~format~~term "Frame Loss" is intendedfor~~reporting Route-Specific Convergence Time~~Ethernet Frames while "Packet Loss"is~~provided~~intended for IP packets. Packet Loss can be measured as a reductionin~~[Po07m]. The Route-Specific~~forwarded traffic from the Throughput [Ba91] of the DUT. Measurement units: Number of offered packets that are not forwarded. Issues: None See Also:Convergence~~Time MAY be used~~Packet Loss 3.4.2 Convergence Packet Loss Definition: The number of packets lost dueto~~benchmark Full~~aConvergence~~when used in combination with many flows matching every FIB entry. In this case~~Event untilFull Convergence~~= max(Route-Specific~~completes. Discussion: Convergence Packet Loss includes packets that were lost and packets that were delayed due to buffering. The Convergence Packet Loss observed in a Packet Sampling Interval may or may not be equal to the number of packets in the offered load during the interval following aConvergence~~Time).~~Event (see Figure 1).Measurement Units:~~seconds~~number of packetsIssues: None See Also:Packet Loss RouteConvergence~~Event~~ConvergenceEventPacket~~Loss Route-Specific~~Sampling Interval Link-State IGP Data Plane RouteConvergence~~3.16 Sustained~~3.4.3 Rate-DerivedConvergence~~Validation Time~~MethodDefinition: The~~amount of~~method to calculate convergencetime~~for which~~benchmarks fromthe~~completion~~amountof~~Full~~time thatConvergence~~is maintained without additional packet loss. Discussion: The purpose~~Packet Loss persists upon occurrenceofa Convergence Event. Rate-Derived Convergence Method can be calculated as the time difference fromthe~~Sustained~~Convergence~~Validation Time is~~Event Instantto~~produce Convergence benchmarks protected against fluctuation in Throughput after the completion of Full Convergence is observed. The RECOMMENDED Sustained Convergence Validation Time to be used is 5 seconds. The BMWG selected 5 seconds based upon RFC 2544 [Ba99] which recommends waiting 2 seconds for residual frames to arrive and 5 seconds for DUT restabilization. Measurement Units: seconds Issues: None See Also: Full Convergence~~theConvergence Recovery~~Instant Link-State IGP Data Plane Route Convergence 3.17 First Route Convergence Time Definition: The amount of time for Convergence Packet Loss until the convergence of a first route entry on the Next-Best Egress Interface, as indicated by the First Route Convergence Instant. Discussion: The First Route Convergence Time benchmarking metric can be measured when benchmarking either Full Convergence or Route-Specific Convergence. When benchmarking Full Convergence, First Route Convergence Time can be measured as the time difference from the Convergence Event Instant and the First Route Convergence~~Instant, as shown with Equation~~4a.~~1.(Equation~~4a) First Route~~1) Rate-DerivedConvergence~~Time~~Method=~~First Route~~ConvergenceRecoveryInstant - Convergence Event~~Instant When benchmarking Route-Specific Convergence, First Route~~Instant. Discussion: It is RECOMMENDED that the Rate-DerivedConvergence~~Time can~~Methodbe measured~~as the minimum Route-Specific Convergence Time, as shown with Equation 4b. (Equation 4b) First Route Convergence Time = min(Route-Specific Convergence Time) First Route~~when benchmarking convergence times. The Rate-DerivedConvergence~~Time should~~Method SHOULDbe measuredwith an Offered Loadat the~~maximum~~Throughput of the DUT. At least one packet per route in the FIB for all routes in the FIB MUST be offered to the DUT within the Packet Sampling Interval.It is possible to measure no packet loss, which results in a Rate-Derived Convergence Time benchmark of zero.Failure to achieve~~the First Route~~FullConvergence~~Instant~~results in a~~First Route~~Rate-DerivedConvergence Time benchmark of infinity. Measurement Units: seconds Issues: None See Also: Convergence Packet Loss~~First Route~~ConvergenceRecoveryInstant~~Link-State IGP Data Plane Route~~Convergence~~3.18 Reversion~~Event Instant FullConvergence~~Time~~3.4.4 Loss-Derived Convergence MethodDefinition: The~~amount of~~method to calculate convergencetime~~for~~benchmarks fromthe~~DUT to complete Full Convergence to the Preferred Egress Interface, instead~~amountof~~the Next-Best Egress Interface, upon recovery~~Convergence Packet Loss. Loss-Derived Convergence Method can be calculatedfrom~~a~~Convergence~~Event. Discussion: Reversion~~Packet Loss as shown with Equation 2. Equation 2 - Loss-DerivedConvergence~~Time is the amount of time for Full~~Method =Convergence~~to the original egress interface. This is achieved by recovering from~~Packets Loss / Offered Load where units are packets / packets/second = seconds Link-State IGP Data Plane Route Convergence Discussion: Ideally,the Convergence~~Event, such as restoring~~Event Transition and Convergence Recovery Transition are instantaneous so thatthe~~failed link. Reversion~~Rate-DerivedConvergence~~Time is measured using~~Method = Loss-Derived Convergence Method. However, router implementations are less than ideal. Loss-Derived Convergence Method gives a better than actual result when converging many routes simultaneously because it ignoresthetransitions. TheRate-Derived Convergence~~Time calculation technique, as provided in~~Method takes the transitions into account.Equation~~1. It is possible~~2 calculates the average convergence time over all routestowhich packetshavebeen sent. The average convergence time is often lower thanthe~~Reversion~~maximum convergence time over all routes, so it can produce a result that is faster than the actual convergence time.. Therefore, Loss-DerivedConvergence~~Time differ from~~Method is not the preferred method to measure convergence benchmarks. For these reasons the RECOMMENDED method to obtain a benchmark metric for convergence time isthe Rate-Derived Convergence~~Time.~~Method.Measurement Units: seconds Issues: None See Also:~~Preferred Egress Interface~~Convergence~~Event~~Packet LossRate-Derived Convergence~~Time 3.19~~Method Route-Specific Convergence Convergence Event Transition Convergence Recovery Transition 3.4.5Packet Sampling Interval Definition: The interval at which the tester (test equipment) polls to make measurements for arriving packet flows. Discussion: At least one packet per route in the FIB for all routes in the FIB MUST be offered to the DUT within the Packet Sampling Interval. Metrics measured at the Packet Sampling Interval MUST include Forwarding Rate and Convergence Packet Loss. Packet Sampling Interval can influence the Convergence Graph. This is particularly true when implementations complete Full Convergence in lesstimethan the Packet Sampling Interval. The Convergence Event Transition and Convergence Recovery TransitionLink-State IGP Data Plane Route Convergencecan become exaggerated when the Packet Sampling Interval is too long.~~This will~~In this condition, the Rate-Derived Convergence Method mayproduce a larger than actual~~Rate-Derived~~convergence time. In such cases the Loss-DerivedConvergence~~Time.~~Method may produce a more accurate result.The recommended value for configuration of the Packet Sampling Interval is provided in [Po07m]. Measurement Units: seconds Issues: None See Also: Convergence Packet Loss Convergence Event Transition Convergence Recovery Transition~~Link-State IGP Data Plane Route~~3.5 Benchmarks 3.5.1 FullConvergence~~3.20 Local Interface~~TimeDefinition:~~An interface on the DUT. Discussion: A failure~~The amountoftime it takes for Full Convergence to occur. Discussion: Full Convergence Time can be determined usingthe~~Local Interface indicates that~~Rate-Derived Convergence Method or Loss-Derived Convergence Method. The Rate-Derived Convergence Method is RECOMMENDED. When measuring Route-Specific Convergence Time, there may be conditions in whichthe~~failure occurred directly on~~maximum Route Specific Convergence Time can be reported asthe~~DUT.~~Full Convergence Time. Full Convergence may or may not be sustained over time. The Sustained Convergence Validation Time MUST be applied.Measurement Units:~~N/A~~secondsIssues: None See Also:~~Neighbor Interface Remote Interface 3.21 Neighbor Interface~~Full Convergence Rate-Derived Convergence Method Loss-Derived Convergence Method 3.5.2 First Route Convergence TimeDefinition: The~~interface on the neighbor router or tester that is directly linked to~~amount of time for Convergence Packet Loss untilthe~~DUT's Local Interface. Discussion: A failure~~convergenceof a~~Neighbor Interface indicates that a failure occurred~~first route entryon~~a neighbor router's interface that directly links~~the~~neighbor router to~~Next-Best Egress Interface, as indicated bythe~~DUT. Measurement Units: N/A Issues: None See Also: Local Interface Remote Interface~~First Route Convergence Instant.Link-State IGP Data Plane Route Convergence~~3.22 Remote Interface Definition: An interface on a neighboring router that is not directly connected to any interface on the DUT. Discussion: A failure of a Remote Interface indicates that the failure occurred on a neighbor router's interface that is not directly connected to the DUT. Measurement Units: N/A Issues: None See Also: Local Interface Neighbor Interface 3.23 Preferred Egress Interface Definition: The outbound interface from the DUT for traffic routed to the preferred next-hop.~~Discussion: The~~Preferred Egress Interface is the egress interface prior to a~~First RouteConvergence~~Event. Measurement~~Time benchmarking metric can be measured when benchmarking either Full Convergence or Route-Specific Convergence. When benchmarking Full Convergence, First Route Convergence Time can be measured as the time difference from the Convergence Event Instant and the First Route Convergence Instant, as shown with Equation 4a. (Equation 4a) First Route Convergence Time = First Route Convergence Instant - Convergence Event Instant First Route Convergence Time should be measured at the maximum Throughput of the DUT. At least one packet per route in the FIB for all routes in the FIB MUST be offered to the DUT within the Packet Sampling Interval. Failure to achieve the First Route Convergence Instant results in a First Route Convergence Time benchmark of infinity. MeasurementUnits:~~N/A~~secondsIssues: None See Also:~~Next-Best Egress Interface 3.24 Next-Best Egress Interface~~Convergence Packet Loss First Route Convergence Instant 3.5.3 Route-Specific Convergence TimeDefinition: The~~outbound interface~~amount of time it takes for Route-Specific Convergence to be completed as calculatedfrom the~~DUT~~amount of Convergence Packet Lossfor~~traffic routed to~~the~~second-best next-hop.~~flow associated to a specific route. Route-Specific Convergence Time can be calculated from Convergence Packet Loss as shown with Equation 3. (Equation 3) Route-Specific Convergence Time = Convergence Packets Loss / Offered Load where units are packets / packets/second = seconds Link-State IGP Data Plane Route Convergence Discussion:It ispossible to provide an offered load that has flows matching every route entry inthe~~same media type~~FIBand~~link speed as~~benchmarking Route-Specific Convergence Time for all route entries. The number of flows that can be measured is dependent uponthe~~Preferred Egress Interface Discussion:~~flow measurement capabilities of the Tester. When benchmarking Route-Specific Convergence, Convergence Packet Loss is measured for specific flow(s) and Equation 3 is applied for each flow. Each flow has a single destination address matching a different route entry.The~~Next-Best Egress Interface becomes~~fastest measurable convergence time is equal tothe~~egress interface after~~time between two consecutive packets ofaflow offered by the Tester. In practice, the fastest measurable convergence time is the Packet Sampling Interval of the Tester. The Route-SpecificConvergence~~Event. Link-State IGP Data Plane Route~~Time benchmarks enable minimum, maximum, average, and median convergence time measurements to be reported by comparing the results for the different route entries. It also enables benchmarking of convergence time when configuring a priority value for route entry(ies). Since multiple Route-Specific Convergence Times can be measured it is possible to have an array of results. The format for reporting Route-SpecificConvergenceTime is provided in [Po07m].Measurement Units:~~N/A~~secondsIssues: None See Also:~~Preferred Egress Interface 3.25 Stale Forwarding~~Convergence Event Convergence Packet Loss Route-Specific Convergence 3.5.4 Sustained Convergence Validation TimeDefinition:~~Forwarding~~The amountof~~traffic to route entries that no longer exist or to route entries with next-hops that are no longer preferred. Discussion: Stale Forwarding can be caused by a~~time for which the completion of FullConvergence~~Event and can manifest as a "black-hole" or microloop that produces~~is maintained without additionalpacket loss.~~Stale Forwarding can exist until Network~~Discussion: The purpose of the SustainedConvergenceValidation Timeis~~completed. Stale Forwarding cannot~~to produce Convergence benchmarks protected against fluctuation in Throughput after the completion of Full Convergence is observed. The RECOMMENDED Sustained Convergence Validation Time tobe~~observed with a single DUT.~~used is 5 seconds. The BMWG selected 5 seconds based upon RFC 2544 [Ba99] which recommends waiting 2 seconds for residual frames to arrive and 5 seconds for DUT restabilization. Link-State IGP Data Plane Route ConvergenceMeasurement Units:~~N/A~~secondsIssues: None See Also:~~Network~~FullConvergence~~3.26 Nested~~Convergence~~Events~~Recovery Instant 3.5.5 Reversion Convergence TimeDefinition: The~~occurrence~~amountof~~a~~time for the DUT to complete FullConvergence~~Event while~~tothe~~route table is converging~~Preferred Egress Interface, instead of the Next-Best Egress Interface, upon recoveryfrom a~~prior~~Convergence Event. Discussion:~~The~~ReversionConvergence~~Events~~Time is the amount of timefor~~a Nested~~FullConvergence~~Event MUST occur with different neighbors. A common observation~~to the original egress interface. This is achieved by recoveringfrom~~a Nested~~theConvergence~~Event will~~Event, such as restoring the failed link. Reversion Convergence Time canbemeasured using the Rate-Derived Convergence Method or Loss-Derived Convergence Method. The Rate-Derived Convergence Method is RECOMMENDED. It is possible to havethe~~withdrawal of routes~~Reversion Convergence Time differfrom~~one neighbor while~~the~~routes of another neighbor are being installed.~~Full Convergence Time.Measurement Units:~~N/A~~secondsIssues: None See Also:Preferred Egress InterfaceConvergence Event~~Link-State IGP Data Plane Route~~Rate-DerivedConvergenceMethod4. IANA Considerations This document requires no IANA considerations. 5. Security Considerations Documents of this type do not directly affect the security of Internet or corporate networks as long as benchmarking is not performed on devices or systems connected to production networks.Security threats and how to counter these in SIP and the media layer is discussed in RFC3261, RFC3550, and RFC3711 and various other drafts. This document attempts to formalize a set of common terminology for benchmarking IGP convergence performance in a lab environment. Link-State IGP Data Plane Route Convergence6. Acknowledgements Thanks to Sue Hares, Al Morton, Kevin Dubray, Ron Bonica, David Ward, Kris Michielsen and the BMWG for their contributions to this work. 7. References 7.1 Normative References [Ba91] Bradner, S. "Benchmarking Terminology for Network Interconnection Devices", RFC1242, July 1991. [Ba99] Bradner, S. and McQuaid, J., "Benchmarking Methodology for Network Interconnect Devices", RFC 2544, March 1999. [Br97] Bradner, S., "Key words for use in RFCs to Indicate [Ca90] Callon, R., "Use of OSI IS-IS for Routing in TCP/IP and Dual Environments", RFC 1195, December 1990. [Ma98] Mandeville, R., "Benchmarking Terminology for LAN Switching Devices", RFC 2285, February 1998. [Mo98] Moy, J., "OSPF Version 2", RFC 2328, IETF, April 1998. [Mo06] Morton, A., et al, "Packet Reordering Metrics", RFC 4737, November 2006. [Po06] Poretsky, S., et al., "Terminology for Benchmarking Network-layer Traffic Control Mechanisms", RFC 4689, November 2006. [Po07a] Poretsky, S., "Benchmarking Applicability for Link-State IGP Data Plane Route Convergence",~~draft-ietf-bmwg-igp-dataplane-conv-app-16,~~draft-ietf-bmwg-igp-dataplane-conv-app-17,work in progress,~~October 2008.~~March 2009.[Po07m] Poretsky, S. and Imhoff, B., "Benchmarking Methodology for Link-State IGP Data Plane Route Convergence",~~draft-ietf-bmwg-igp-dataplane-conv-meth-16,~~draft-ietf-bmwg-igp-dataplane-conv-meth-17,work in progress,~~October 2008. Link-State IGP Data Plane Route Convergence~~March 2009.7.2 Informative References [Ca01] S. Casner, C. Alaettinoglu, and C. Kuan, "A Fine-Grained View of High Performance Networking", NANOG 22, June 2001. [Ci03] L. Ciavattone, A. Morton, and G. Ramachandran, "Standardized Active Measurements on a Tier 1 IP Backbone", IEEE Communications Magazine, pp90-97, May 2003.Link-State IGP Data Plane Route Convergence8. Author's Address Scott Poretsky Allot Communications 67 South Bedford Street, Suite 400 Burlington, MA 01803 USA Phone: + 1 508 309 2179 Email: sporetsky@allot.com Brent Imhoff Juniper Networks 1194 North Mathilda Ave Sunnyvale, CA 94089 USA Phone: + 1 314 378 2571 EMail: bimhoff@planetspork.com~~Full Copyright Statement Copyright (C) The IETF Trust (2008). 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. Link-State IGP Data Plane Route Convergence 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.~~