draft-ietf-bmwg-reset-04.txt   draft-ietf-bmwg-reset-05.txt 
Benchmarking Methodology WG Rajiv Asati Benchmarking Methodology WG Rajiv Asati
Internet Draft Cisco Internet Draft Cisco
Updates: 2544 (if approved) Carlos Pignataro Updates: 2544 (if approved) Carlos Pignataro
Intended status: Informational Cisco Intended status: Informational Cisco
Expires: June 2011 Fernando Calabria Expires: June 2011 Fernando Calabria
Cisco Cisco
Cesar Olvera Cesar Olvera
Consulintel Consulintel
December 8, 2010 December 18, 2010
Device Reset Characterization Device Reset Characterization
draft-ietf-bmwg-reset-04 draft-ietf-bmwg-reset-05
Abstract Abstract
An operational forwarding device may need to be re-started An operational forwarding device may need to be re-started
(automatically or manually) for a variety of reasons, an event that (automatically or manually) for a variety of reasons, an event that
we call a "reset" in this document. Since there may be an we call a "reset" in this document. Since there may be an
interruption in the forwarding operation during a reset, it is interruption in the forwarding operation during a reset, it is
useful to know how long a device takes to resume the forwarding useful to know how long a device takes to resume the forwarding
operation. operation.
skipping to change at page 2, line 10 skipping to change at page 2, line 10
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress." reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This Internet-Draft will expire on June 8, 2011. This Internet-Draft will expire on June 18, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 10 skipping to change at page 3, line 10
respect to this document. Code Components extracted from this respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License. warranty as described in the Simplified BSD License.
Table of Contents Table of Contents
1. Key Words to Reflect Requirements..............................4 1. Key Words to Reflect Requirements..............................4
2. Introduction...................................................4 2. Introduction...................................................4
2.1. Scope.....................................................4 2.1. Scope.....................................................4
2.2. Recovery Time Measurement Methods.........................5 2.2. Reset Characterization....................................5
2.3. Reporting Format..........................................6 2.3. Recovery Time Measurement Methods.........................6
3. Test Requirements..............................................7 2.4. Reporting Format..........................................7
4. Reset Test.....................................................8 3. Test Requirements..............................................8
4.1. Hardware Reset Test.......................................9 4. Reset Test.....................................................9
4.1.1. Routing Processor (RP) / Routing Engine Reset........9 4.1. Hardware Reset Test......................................10
4.1.1.1. RP Reset for a single-RP device (REQUIRED)......9 4.1.1. Routing Processor (RP) / Routing Engine Reset.......10
4.1.1.1. RP Reset for a single-RP device (REQUIRED).....10
4.1.1.2. RP Switchover for a multiple-RP device (OPTIONAL) 4.1.1.2. RP Switchover for a multiple-RP device (OPTIONAL)
........................................................10 ........................................................11
4.1.2. Line Card (LC) Removal and Insertion (REQUIRED).....12 4.1.2. Line Card (LC) Removal and Insertion (REQUIRED).....13
4.2. Software Reset Test......................................12 4.2. Software Reset Test......................................13
4.2.1. Operating System (OS) Reset (REQUIRED)..............13 4.2.1. Operating System (OS) Reset (REQUIRED)..............14
4.2.2. Process Reset (OPTIONAL)............................13 4.2.2. Process Reset (OPTIONAL)............................14
4.3. Power Interruption Test..................................14 4.3. Power Interruption Test..................................15
4.3.1. Power Interruption (REQUIRED).......................15 4.3.1. Power Interruption (REQUIRED).......................16
5. Security Considerations.......................................16 5. Security Considerations.......................................17
6. IANA Considerations...........................................16 6. IANA Considerations...........................................17
7. Acknowledgments...............................................16 7. Acknowledgments...............................................17
8. References....................................................17 8. References....................................................18
8.1. Normative References.....................................17 8.1. Normative References.....................................18
8.2. Informative References...................................17 8.2. Informative References...................................18
Authors' Addresses...............................................18 Authors' Addresses...............................................19
1. Key Words to Reflect Requirements 1. Key Words to Reflect Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14, RFC 2119 document are to be interpreted as described in BCP 14, RFC 2119
[RFC2119]. RFC 2119 defines the use of these key words to help make [RFC2119]. RFC 2119 defines the use of these key words to help make
the intent of standards track documents as clear as possible. While the intent of standards track documents as clear as possible. While
this document uses these keywords, this document is not a standards this document uses these keywords, this document is not a standards
track document. track document.
skipping to change at page 4, line 43 skipping to change at page 4, line 43
This document specifies a methodology for characterizing reset (and This document specifies a methodology for characterizing reset (and
recovery time) during benchmarking of forwarding devices, and recovery time) during benchmarking of forwarding devices, and
provides clarity and consistency in reset procedures beyond what is provides clarity and consistency in reset procedures beyond what is
specified in [RFC2544]. Software upgrades involve additional specified in [RFC2544]. Software upgrades involve additional
benchmarking complexities and are outside the scope of this benchmarking complexities and are outside the scope of this
document. document.
These procedures may be used by other benchmarking documents such as These procedures may be used by other benchmarking documents such as
[RFC2544], [RFC5180], [RFC5695], etc., and is expected that other [RFC2544], [RFC5180], [RFC5695], etc., and is expected that other
protocol-specific benchmarking documents would reference this protocol-specific benchmarking documents would reference this
document for reset recovery time characterization. document for reset recovery time characterization. Specific Routing
Information Base (RIB) and Forwarding Information Base (FIB) scaling
considerations are outside the scope of this document and can be
quite complex to characterize. However, other documents can
characterize specific dynamic protocols scaling and interactions and
leverage and augment the reset tests defined in this document.
This document updates Section 26.6 of [RFC2544]. This document updates Section 26.6 of [RFC2544].
This document focuses only on the reset criterion of benchmarking, This document focuses only on the reset criterion of benchmarking,
and presumes that it would be beneficial to [RFC5180], [RFC5695], and presumes that it would be beneficial to [RFC5180], [RFC5695],
and other BMWG benchmarking efforts. and other IETF Benchmarking Methodology Working Group (BMWG)
efforts.
2.2. Recovery Time Measurement Methods 2.2. Reset Characterization
Definition
Reset Time is the total time when a device is determined to be out
of operation, and includes the time to perform the reset and the
time to recover from it.
Discussion
During a period of time after a reset or power up, network devices
may not accept and forward frames. The duration of this period of
forwarding unavailability can be useful in evaluating devices. In
addition, some network devices require some form of reset when
specific setup variables are modified. If the reset period were
long it might discourage network managers from modifying these
variables on production networks.
The events characterized in this document are entire reset events.
That is, the recovery period measured includes the time to perform
the reset and the time to recover from it. Some reset events will
be atomic (such as pressing a reset button) while others (such as
power cycling) may comprise multiple actions with a recognized
interval between them. In both cases, the duration considered is
from the start of the event until full recovery of forwarding
after the completion of the reset events.
Measurement units
Time in milliseconds, providing sufficient resolution to
distinguish between different trials and different
implementations. See Section 2.4.
Issues
There are various types of Reset: Hardware resets, software
resets, and power interruption. See Section 4.
2.3. Recovery Time Measurement Methods
The 'recovery time' is the time during which the traffic forwarding The 'recovery time' is the time during which the traffic forwarding
is temporarily interrupted following a reset event. Strictly is temporarily interrupted following a reset event. Strictly
speaking, this is the time over which one or more frames are lost. speaking, this is the time over which one or more frames are lost.
This definition is similar to that of 'Loss of connectivity period' This definition is similar to that of 'Loss of connectivity period'
defined in [IGPConv] section 4. defined in [IGPConv] section 4.
There are two accepted methods to measure the 'recovery time': There are two accepted methods to measure the 'recovery time':
1. Frame-Loss Method - This method requires test tool capability 1. Frame-Loss Method - This method requires test tool capability
skipping to change at page 6, line 5 skipping to change at page 6, line 43
stopped. The difference between Timestamp B and Timestamp A is stopped. The difference between Timestamp B and Timestamp A is
the recovery time. the recovery time.
The tester / operator MAY use either method for recovery time The tester / operator MAY use either method for recovery time
measurement depending on the test tool capability. However, the measurement depending on the test tool capability. However, the
Frame-loss method SHOULD be used if the test tool is capable of (a) Frame-loss method SHOULD be used if the test tool is capable of (a)
counting the number of lost frames per stream, and (b) transmitting counting the number of lost frames per stream, and (b) transmitting
test frame despite the physical link status, whereas Time-stamp test frame despite the physical link status, whereas Time-stamp
method SHOULD be used if the test tool is capable of (a) time- method SHOULD be used if the test tool is capable of (a) time-
stamping each frame, (b) monitoring received frame's timestamp, and stamping each frame, (b) monitoring received frame's timestamp, and
(c) transmitting frames only if the physical link status is UP. (c) transmitting frames only if the physical link status is UP. That
is, specific test tool capabilities may dictate which method to use.
2.3. Reporting Format If the test tool supports both methods based on its capabilities,
the tester / operator SHOULD use the one that provides more
accuracy.
2.4. Reporting Format
All reset results are reported in a simple statement including the All reset results are reported in a simple statement including the
frame loss (if measured) and recovery times. frame loss (if measured) and recovery times.
For each test case, it is RECOMMENDED that the following parameters For each test case, it is RECOMMENDED that the following parameters
be reported in these units: be reported in these units:
Parameter Units or Examples Parameter Units or Examples
----------------------------------------------------------------- -----------------------------------------------------------------
skipping to change at page 7, line 17 skipping to change at page 8, line 14
configuration, and deployed methodologies that may influence the configuration, and deployed methodologies that may influence the
overall recovery time MUST be listed. (Refer to the additional overall recovery time MUST be listed. (Refer to the additional
factors listed in Section 3). factors listed in Section 3).
The reporting of results MUST regard repeatability considerations The reporting of results MUST regard repeatability considerations
from Section 4 of [RFC2544]. It is RECOMMENDED to perform multiple from Section 4 of [RFC2544]. It is RECOMMENDED to perform multiple
trials and report average results. trials and report average results.
3. Test Requirements 3. Test Requirements
In order to provide consistent and fairness while benchmarking a set Tests SHOULD first be performed such that the forwarding state re-
of different DUTs, the Network tester / operator MUST (a) use establishment is independent from an external source (i.e., using
static address resolution, routing and forwarding configuration, and
not dynamic protocols). However tests MAY subsequently be performed
using dynamic protocols that the forwarding state depends on (e.g.,
dynamic Interior Gateway Protocols (IGP), ARP, PPP Control
Protocols, etc.) The considerations in this Section apply.
In order to provide consistence and fairness while benchmarking a
set of different DUTs, the Network tester / operator MUST (a) use
identical control and data plane information during testing, (b) identical control and data plane information during testing, (b)
document & report any factors that may influence the overall time document & report any factors that may influence the overall time
after reset / convergence. after reset / convergence.
Some of these factors include: Some of these factors include:
1. Type of reset - Hardware (line-card crash, etc.) vs. Software 1. Type of reset - Hardware (line-card crash, etc.) vs. Software
(protocol reset, process crash, etc.) or even complete power (protocol reset, process crash, etc.) or even complete power
failures failures
skipping to change at page 9, line 20 skipping to change at page 10, line 20
A "hardware reset" generally involves the re-initialization of one A "hardware reset" generally involves the re-initialization of one
or more physical components in the DUT, but not the entire DUT. or more physical components in the DUT, but not the entire DUT.
A hardware reset is executed by the operator for example by physical A hardware reset is executed by the operator for example by physical
removal of a hardware component, by pressing on a "reset" button for removal of a hardware component, by pressing on a "reset" button for
the component, or could even be triggered from the command line the component, or could even be triggered from the command line
interface. interface.
Reset procedures that do not require the physical removal and Reset procedures that do not require the physical removal and
insertion of a hardware component are RECOMMENDED. These include insertion of a hardware component are RECOMMENDED. These include
using the CLI or a physical switch or button. If such procedures using the Command Line Interface (CLI) or a physical switch or
cannot be performed (e.g., for lack of platform support, or because button. If such procedures cannot be performed (e.g., for lack of
the corresponding Test Case calls for them), human operation time platform support, or because the corresponding Test Case calls for
SHOULD be minimized across different platforms and Test Cases as them), human operation time SHOULD be minimized across different
much as possible, and variation in human operator time SHOULD also platforms and Test Cases as much as possible, and variation in human
be minimized across different vendors products as much as practical, operator time SHOULD also be minimized across different vendors
by having the same person perform the operation, and by practicing products as much as practical, by having the same person perform the
the operation. operation, and by practicing the operation.
For routers that do not contain separate Routing Processor and Line For routers that do not contain separate Routing Processor and Line
Card modules, the hardware reset tests are not performed since they Card modules, the hardware reset tests are not performed since they
are not relevant; instead, the power interruption tests MUST be are not relevant; instead, the power interruption tests MUST be
performed (see Section 4.3) in these cases. performed (see Section 4.3) in these cases.
4.1.1. Routing Processor (RP) / Routing Engine Reset 4.1.1. Routing Processor (RP) / Routing Engine Reset
The Routing Processor (RP) is the DUT module that is primarily The Routing Processor (RP) is the DUT module that is primarily
concerned with Control Plane functions. concerned with Control Plane functions.
skipping to change at page 10, line 28 skipping to change at page 11, line 28
attain the maximum forwarding throughput. This enables a finer attain the maximum forwarding throughput. This enables a finer
granularity in the recovery time measurement. granularity in the recovery time measurement.
Third, perform the Route Processor (RP) hardware reset at this Third, perform the Route Processor (RP) hardware reset at this
point. This entails for example physically removing the RP to point. This entails for example physically removing the RP to
later re-insert it, or triggering a hardware reset by other means later re-insert it, or triggering a hardware reset by other means
(e.g., command line interface, physical switch, etc.) (e.g., command line interface, physical switch, etc.)
Finally, the characterization is completed by recording the frame Finally, the characterization is completed by recording the frame
loss or time stamps (as reported by the test tool) and calculating loss or time stamps (as reported by the test tool) and calculating
the recovery time (as defined in Section 2.2). the recovery time (as defined in Section 2.3).
Reporting format Reporting format
The reporting format is defined in Section 2.3. The reporting format is defined in Section 2.4.
4.1.1.2. RP Switchover for a multiple-RP device (OPTIONAL) 4.1.1.2. RP Switchover for a multiple-RP device (OPTIONAL)
Objective Objective
To characterize time needed for "secondary" Route Processor To characterize time needed for "secondary" Route Processor
(sometimes referred to as "backup" RP) of a DUT to become active (sometimes referred to as "backup" RP) of a DUT to become active
after a "primary" (or "active") Route Processor hardware reset. after a "primary" (or "active") Route Processor hardware reset.
This process is often referred to as "RP Switchover". The This process is often referred to as "RP Switchover". The
characterization in this test should be done for the default DUT characterization in this test should be done for the default DUT
skipping to change at page 11, line 34 skipping to change at page 12, line 34
Third, perform the primary Route Processor (RP) hardware reset at Third, perform the primary Route Processor (RP) hardware reset at
this point. This entails for example physically removing the RP, this point. This entails for example physically removing the RP,
or triggering a hardware reset by other means (e.g., command line or triggering a hardware reset by other means (e.g., command line
interface, physical switch, etc.) It is up to the operator to interface, physical switch, etc.) It is up to the operator to
decide if the primary RP needs to be re-inserted after a grace decide if the primary RP needs to be re-inserted after a grace
period or not. period or not.
Finally, the characterization is completed by recording the frame Finally, the characterization is completed by recording the frame
loss or time stamps (as reported by the test tool) and calculating loss or time stamps (as reported by the test tool) and calculating
the recovery time (as defined in Section 2.2). the recovery time (as defined in Section 2.3).
Reporting format Reporting format
The reset results are potentially reported twice, one for the The reset results are potentially reported twice, one for the
default switchover behavior (i.e., the DUT without any switchover- default switchover behavior (i.e., the DUT without any switchover-
specific enhanced configuration) and the other for the switchover- specific enhanced configuration) and the other for the switchover-
specific behavior if it exists (i.e., the DUT configured for specific behavior if it exists (i.e., the DUT configured for
optimized switchover capabilities that minimize the downtime optimized switchover capabilities that minimize the downtime
during the actual switchover). during the actual switchover).
The reporting format is defined in Section 2.3, and also includes The reporting format is defined in Section 2.4, and also includes
any specific redundancy scheme in place. any specific redundancy scheme in place.
4.1.2. Line Card (LC) Removal and Insertion (REQUIRED) 4.1.2. Line Card (LC) Removal and Insertion (REQUIRED)
The Line Card (LC) is the DUT component that is responsible with The Line Card (LC) is the DUT component that is responsible with
packet forwarding. packet forwarding.
Objective Objective
To characterize time needed for a DUT to recover from a Line Card To characterize time needed for a DUT to recover from a Line Card
skipping to change at page 12, line 36 skipping to change at page 13, line 36
Second, ensure that the DUT is able to forward the traffic for at Second, ensure that the DUT is able to forward the traffic for at
least 15 seconds before any test activities are performed. The least 15 seconds before any test activities are performed. The
traffic should use the minimum frame size possible on the media traffic should use the minimum frame size possible on the media
used in the testing and rate should be sufficient for the DUT to used in the testing and rate should be sufficient for the DUT to
attain the maximum forwarding throughput. This enables a finer attain the maximum forwarding throughput. This enables a finer
granularity in the recovery time measurement. granularity in the recovery time measurement.
Third, perform the Line Card (LC) hardware reset at this point. Third, perform the Line Card (LC) hardware reset at this point.
This entails for example physically removing the LC to later re- This entails for example physically removing the LC to later re-
insert it, or triggering a hardware reset by other means (e.g., insert it, or triggering a hardware reset by other means (e.g.,
command line interface (CLI), physical switch, etc.). CLI, physical switch, etc.).
Finally, the characterization is completed by recording the frame Finally, the characterization is completed by recording the frame
loss or time stamps (as reported by the test tool) and calculating loss or time stamps (as reported by the test tool) and calculating
the recovery time (as defined in Section 2.2). the recovery time (as defined in Section 2.3).
Reporting Format Reporting Format
The reporting format is defined in Section 2.3. The reporting format is defined in Section 2.4.
4.2. Software Reset Test 4.2. Software Reset Test
To characterize time needed for a DUT to recover from the software To characterize time needed for a DUT to recover from the software
reset. reset.
In contrast to a "hardware reset", a "software reset" involves only In contrast to a "hardware reset", a "software reset" involves only
the re-initialization of the execution, data structures, and partial the re-initialization of the execution, data structures, and partial
state within the software running on the DUT module(s). state within the software running on the DUT module(s).
A software reset is initiated for example from the DUT's Command A software reset is initiated for example from the DUT's CLI.
Line Interface (CLI).
4.2.1. Operating System (OS) Reset (REQUIRED) 4.2.1. Operating System (OS) Reset (REQUIRED)
Objective Objective
To characterize time needed for a DUT to recover from an Operating To characterize time needed for a DUT to recover from an Operating
System (OS) software reset. System (OS) software reset.
Procedure Procedure
skipping to change at page 13, line 34 skipping to change at page 14, line 33
or perform additional Operating System task. or perform additional Operating System task.
Second, ensure that the DUT is able to forward the traffic for at Second, ensure that the DUT is able to forward the traffic for at
least 15 seconds before any test activities are performed. The least 15 seconds before any test activities are performed. The
traffic should use the minimum frame size possible on the media traffic should use the minimum frame size possible on the media
used in the testing and rate should be sufficient for the DUT to used in the testing and rate should be sufficient for the DUT to
attain the maximum forwarding throughput. This enables a finer attain the maximum forwarding throughput. This enables a finer
granularity in the recovery time measurement. granularity in the recovery time measurement.
Third, trigger an Operating System re-initialization in the DUT, Third, trigger an Operating System re-initialization in the DUT,
by operational means such as use of the DUT's Command Line by operational means such as use of the DUT's CLI or other
Interface (CLI) or other management interface. management interface.
Finally, the characterization is completed by recording the frame Finally, the characterization is completed by recording the frame
loss or time stamps (as reported by the test tool) and calculating loss or time stamps (as reported by the test tool) and calculating
the recovery time (as defined in Section 2.2). the recovery time (as defined in Section 2.3).
Reporting format Reporting format
The reporting format is defined in Section 2.3. The reporting format is defined in Section 2.4.
4.2.2. Process Reset (OPTIONAL) 4.2.2. Process Reset (OPTIONAL)
Objective Objective
To characterize time needed for a DUT to recover from a software To characterize time needed for a DUT to recover from a software
process reset. process reset.
Such time period may depend upon the number and types of process Such time period may depend upon the number and types of process
running in the DUT and which ones are tested. Different running in the DUT and which ones are tested. Different
implementations of forwarding devices include various common implementations of forwarding devices include various common
skipping to change at page 14, line 30 skipping to change at page 15, line 30
Second, ensure that the DUT is able to forward the traffic for at Second, ensure that the DUT is able to forward the traffic for at
least 15 seconds before any test activities are performed. The least 15 seconds before any test activities are performed. The
traffic should use the minimum frame size possible on the media traffic should use the minimum frame size possible on the media
used in the testing and rate should be sufficient for the DUT to used in the testing and rate should be sufficient for the DUT to
attain the maximum forwarding throughput. This enables a finer attain the maximum forwarding throughput. This enables a finer
granularity in the recovery time measurement. granularity in the recovery time measurement.
Third, trigger a process reset for each process running in the DUT Third, trigger a process reset for each process running in the DUT
and considered for testing from a management interface (e.g., by and considered for testing from a management interface (e.g., by
means of the Command Line Interface (CLI), etc.) means of the CLI, etc.)
Finally, the characterization is completed by recording the frame Finally, the characterization is completed by recording the frame
loss or time stamps (as reported by the test tool) and calculating loss or time stamps (as reported by the test tool) and calculating
the recovery time (as defined in Section 2.2). the recovery time (as defined in Section 2.3).
Reporting format Reporting format
The reporting format is defined in Section 2.3, and is used for The reporting format is defined in Section 2.4, and is used for
each process running in the DUT and tested. Given the each process running in the DUT and tested. Given the
implementation nature of this test, details of the actual process implementation nature of this test, details of the actual process
tested should be included along with the statement. tested should be included along with the statement.
4.3. Power Interruption Test 4.3. Power Interruption Test
"Power interruption" refers to the complete loss of power on the "Power interruption" refers to the complete loss of power on the
DUT. It can be viewed as a special case of a hardware reset, DUT. It can be viewed as a special case of a hardware reset,
triggered by the loss of the power supply to the DUT or its triggered by the loss of the power supply to the DUT or its
components, and is characterized by the re-initialization of all components, and is characterized by the re-initialization of all
skipping to change at page 15, line 41 skipping to change at page 16, line 41
Third, interrupt the power (AC or DC) that feeds the corresponding Third, interrupt the power (AC or DC) that feeds the corresponding
DUTs power supplies at this point. This entails for example DUTs power supplies at this point. This entails for example
physically removing the power supplies in the DUT to later re- physically removing the power supplies in the DUT to later re-
insert them, or simply disconnecting or switching off their power insert them, or simply disconnecting or switching off their power
feeds (AC or DC as applicable). The actual power interruption feeds (AC or DC as applicable). The actual power interruption
should last at least 15 seconds. should last at least 15 seconds.
Finally, the characterization is completed by recording the frame Finally, the characterization is completed by recording the frame
loss or time stamps (as reported by the test tool) and calculating loss or time stamps (as reported by the test tool) and calculating
the recovery time (as defined in Section 2.2). the recovery time (as defined in Section 2.3).
For easier comparison with other testing, the 15 seconds are For easier comparison with other testing, the 15 seconds are
removed from the reported recovery time. removed from the reported recovery time.
Reporting format Reporting format
The reporting format is defined in Section 2.3. The reporting format is defined in Section 2.4.
5. Security Considerations 5. Security Considerations
Benchmarking activities, as described in this memo, are limited to Benchmarking activities, as described in this memo, are limited to
technology characterization using controlled stimuli in a laboratory technology characterization using controlled stimuli in a laboratory
environment, with dedicated address space and the constraints environment, with dedicated address space and the constraints
specified in the sections above. specified in the sections above.
The benchmarking network topology will be an independent test setup The benchmarking network topology will be an independent test setup
and MUST NOT be connected to devices that may forward the test and MUST NOT be connected to devices that may forward the test
 End of changes. 28 change blocks. 
57 lines changed or deleted 113 lines changed or added

This html diff was produced by rfcdiff 1.40. The latest version is available from http://tools.ietf.org/tools/rfcdiff/