Internet Engineering Task Force (IETF) R. Asati
Request for Comments: 6201 C. Pignataro
Updates: 1242, 2544 F. Calabria
Category: Informational Cisco
ISSN: 2070-1721 C. Olvera
Consulintel
March 2011
Device Reset Characterization
Abstract
抽象
An operational forwarding device may need to be restarted (automatically or manually) for a variety of reasons, an event called a "reset" in this document. Since there may be an interruption in the forwarding operation during a reset, it is useful to know how long a device takes to resume the forwarding operation.
演算転送装置は、イベントが本書で「リセット」と呼ばれる、様々な理由のために（自動または手動で）再起動する必要があるかもしれません。リセット時の転送操作が中断される可能性があるので、デバイスが転送動作を再開するのにかかるどのくらい知っておくと便利です。
This document specifies a methodology for characterizing reset (and reset time) during benchmarking of forwarding devices and provides clarity and consistency in reset test procedures beyond what is specified in RFC 2544. Therefore, it updates RFC 2544. This document also defines the benchmarking term "reset time" and, only in this, updates RFC 1242.
この文書は、転送装置のベンチマークの間（及び時間をリセット）リセットを特徴付けるための方法を指定し、したがって、RFC 2544で指定されているものを超えてリセット試験手順において明瞭さと一貫性を提供し、それは、「この文書はまた、ベンチマークの用語を定義するRFC 2544を更新します時間をリセット」と、これだけ、アップデートRFC 1242インチ
Status of This Memo
このメモのステータス
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはインターネット標準化過程仕様ではありません。それは、情報提供の目的のために公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。 IESGによって承認されていないすべての文書がインターネットStandardのどんなレベルの候補です。 RFC 5741のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6201.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6201で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2011 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Scope ......................................................3
1.2. Reset Time .................................................4
1.3. Reset Time Measurement Methods .............................5
1.4. Reporting Format ...........................................6
2. Key Words to Reflect Requirements ...............................7
3. Test Requirements ...............................................7
4. Reset Tests .....................................................8
4.1. Hardware Reset Tests .......................................9
4.1.1. Routing Processor (RP) / Routing Engine Reset .......9
4.1.2. Line Card (LC) Removal and Insertion (REQUIRED) ....11
4.2. Software Reset Tests ......................................12
4.2.1. Operating System (OS) Reset (REQUIRED) .............12
4.2.2. Process Reset (OPTIONAL) ...........................13
4.3. Power Interruption Test ...................................14
4.3.1. Power Interruption (REQUIRED) ......................14
5. Security Considerations ........................................15
6. Acknowledgments ................................................16
7. References .....................................................16
7.1. Normative References ......................................16
7.2. Informative References ....................................16
An operational forwarding device (or one of its components) may need to be restarted for a variety of reasons, an event called a "reset" in this document. Since there may be an interruption in the forwarding operation during a reset, it is useful to know how long a device takes to resume the forwarding operation. In other words, the duration of the recovery time following the reset (see Section 1.2, "Reset Time") is what is in question.
演算転送デバイス（またはそのコンポーネントの1つ）は、イベントが本書で「リセット」と呼ばれる、様々な理由で再起動する必要があるかもしれません。リセット時の転送操作が中断される可能性があるので、デバイスが転送動作を再開するのにかかるどのくらい知っておくと便利です。つまり、リセット後の回復時間の期間は、問題のあるものである（「時間をリセット」、1.2節を参照してください）。
However, the answer to this question is no longer simple and straightforward as the modern forwarding devices employ many hardware advancements (distributed forwarding, etc.) and software advancements (graceful restart, etc.) that influence the recovery time after the reset.
現代の転送デバイスは、多くのハードウェアの進歩（分散フォワーディングなど）およびリセット後の回復時間に影響を与えるソフトウェアの進歩（グレースフルリスタートなど）を使用しかし、この質問に対する答えは、もはや単純明快ではありません。
This document specifies a methodology for characterizing reset (and reset time) during benchmarking of forwarding devices and provides clarity and consistency in reset procedures beyond what is specified in [RFC2544]. Software upgrades involve additional benchmarking complexities and are outside the scope of this document.
この文書は、転送装置のベンチマークの間（及び時間をリセット）リセットを特徴付けるための方法を指定し、[RFC2544]で指定されているものを超えてリセット手順で明瞭かつ一貫性を提供します。ソフトウェアのアップグレードは追加のベンチマークの複雑さを伴い、この文書の範囲外です。
These procedures may be used by other benchmarking documents such as [RFC2544], [RFC5180], [RFC5695], etc., and it is expected that other protocol-specific benchmarking documents will reference this 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 as well as leverage and augment the reset tests defined in this document.
これらの手順は、等[RFC2544]、[RFC5180]、[RFC5695]のような他のベンチマークドキュメントで使用されてもよく、他のプロトコル固有のベンチマークドキュメントがリセット回復時間の特性のために、この文書を参照することが期待されます。特定のルーティング情報ベース（RIB）と転送情報ベース（FIB）スケーリングの考慮事項は、この文書の範囲外であると特徴づけするのは非常に複雑になることがあります。しかし、他の文書は、特定のダイナミックプロトコルスケーリングとの相互作用と同様にレバレッジを特徴付け、この文書で定義されたリセットテストを増やすことができます。
This document updates Section 26.6 of [RFC2544] and defines the benchmarking term "reset time", updating [RFC1242].
この文書では、[RFC2544]のセクション26.6を更新し、ベンチマーク用語「時間をリセット」、更新[RFC1242]を定義します。
This document focuses only on the reset criterion of benchmarking and presumes that it would be beneficial to [RFC5180], [RFC5695], and other IETF Benchmarking Methodology Working Group (BMWG) efforts.
この文書では、唯一のベンチマークのリセット基準に焦点を当て、それが[RFC5180]、[RFC5695]、および他のIETFベンチマーク手法ワーキンググループ（BMWG）の努力に有益であろうことを前提としています。
Definition
定義
Reset time is the total time that 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 1.4.
時間は、ミリ秒単位で、異なる試験と異なる実装を区別するのに十分な解像度を提供します。セクション1.4を参照してください。
Issues
問題
There are various types of resets: hardware resets, software resets, and power interruptions. See Section 4.
ハードウェアリセット、ソフトウェアリセット、および停電：リセットの様々な種類があります。第4節を参照してください。
See Also
参照してください
This definition updates [RFC1242].
この定義の更新[RFC1242]。
The reset time is the time during which traffic forwarding is temporarily interrupted following a reset event. Strictly speaking, this is the time over which one or more frames are lost. This definition is similar to that of "Loss of Connectivity Period" defined in [IGPConv], Section 4.
リセット時間は、トラフィックの転送が一時的にリセットイベント次中断されている時間です。厳密に言えば、これは、1つ以上のフレームが失わされる時間です。この定義は、[IGPConv]で定義された「接続期間の喪失」、第4節の場合と同様です。
There are two accepted methods to measure the reset time:
リセット時間を測定するための2つの受け入れられた方法があります。
1. Frame-Loss Method - This method requires test tool capability to monitor the number of lost frames. In this method, the offered stream rate (frames per second) must be known. The reset time is calculated per the equation below:
1.フレーム・ロス法 - この方法では、失われたフレームの数を監視するために、テストツールの機能を必要とします。この方法では、提供されるストリームレート（毎秒フレーム）が知られていなければなりません。リセット時間は、以下の式ごとに計算されます。
Frames_lost (packets)
Reset_time = -------------------------------------
Offered_rate (packets per second)
2. Timestamp Method - This method requires test tool capability to timestamp each frame. In this method, the test tool timestamps each transmitted frame and monitors the received frame's timestamp. During the test, the test tool records the timestamp (Timestamp A) of the frame that was last received prior to the reset interruption and the timestamp of the first frame after the interruption stopped (Timestamp B). The difference between Timestamp B and Timestamp A is the reset time.
2.タイムスタンプ方法 - この方法は、各フレームをタイムスタンプするためにテストツール能力を必要とします。この方法では、テストツールは、各送信されたフレームをタイムスタンプと受信したフレームのタイムスタンプを監視します。試験中、試験ツールが中断が（タイムスタンプB）が停止した後、前リセット割り込みと最初のフレームのタイムスタンプを最後に受信したフレームのタイムスタンプ（タイムスタンプA）を記録します。タイムスタンプBとタイムスタンプAとの間の差は、リセット時間です。
The tester/operator MAY use either method for reset time measurement depending on the test tool capability. However, the 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 test frame despite the physical link status, whereas the Timestamp method SHOULD be used if the test tool is capable of (a) timestamping each frame, (b) monitoring received frame's timestamp, and (c) transmitting frames only if the physical link status is UP. That is, specific test tool capabilities may dictate which method to use. If the test tool supports both methods based on its capabilities, the tester/operator SHOULD use the one that provides more accuracy.
テスター/オペレータは、テストツールの能力に応じたリセット時間測定のための方法も使用することができます。場合タイムスタンプ方法を使用すべきであるのに対し、テストツールは、（a）は、物理リンクステータスにもかかわらず、ストリームあたり失われたフレームと、（b）は、送信テストフレームの数をカウントすることが可能である場合は、フレーム損失方法が使用されてくださいテストツールは、（a）は（b）のモニタリングは、フレームのタイムスタンプを受信し、および（c）物理リンクステータスがUPである場合にのみフレームを送信し、各フレームをタイムスタンプすることが可能です。これは、特定のテスト・ツールの機能は、使用する方法を指示することができるされています。テストツールは、その能力に基づいて、両方の方法をサポートしている場合は、テスター/オペレータは、より精度を提供するものを使用すべきです。
All reset results are reported in a simple statement including the frame loss (if measured) and reset times.
すべてのリセットの結果は、フレーム損失を含む簡単な文で報告された（測定した場合）と回リセットされます。
For each test case, it is RECOMMENDED that the following parameters be reported in these units:
各テストケースのために、以下のパラメータは、これらの単位で報告されることをお勧めします。
Parameter Units or Examples
---------------------------------------------------------------
Throughput Frames per second and bits per second
スループットフレーム毎秒毎秒のビット
Loss (average) Frames
損失（平均）フレーム
Reset Time (average) Milliseconds
時間（平均）ミリ秒をリセット
Number of trials Integer count
トライアル整数カウント数
Protocol IPv4, IPv6, MPLS, etc.
プロトコルはIPv4、IPv6の、MPLSなど
Frame Size Octets
フレームサイズのオクテット
Port Media Ethernet, Gigabit Ethernet (GbE), Packet over SONET (POS), etc.
ポートメディアイーサネット、ギガビット・イーサネット（GbEの）、パケットSONET（POS）を超えるなど
Port Speed 10 Gbps, 1 Gbps, 100 Mbps, etc.
ポート速度10 Gbpsの、1 Gbpsの、100 Mbpsの、など
Interface Encap. Ethernet, Ethernet VLAN, PPP, High-Level Data Link Control (HDLC), etc.
ENCAPをインタフェース。イーサネット、イーサネットVLAN、PPP、ハイレベルデータリンク制御（HDLC）など
For mixed protocol environments, frames SHOULD be distributed between all the different protocols. The distribution MAY approximate the network conditions of deployment. In all cases, the details of the mixed protocol distribution MUST be included in the reporting.
混合プロトコル環境では、フレームが全て異なるプロトコル間で分配されなければなりません。分布は、展開のネットワーク条件に近づけるかもしれません。すべての場合において、混合プロトコル分布の詳細は報告に含まれなければなりません。
Additionally, the DUT (Device Under Test) or SUT (System Under Test) and test bed provisioning, port and line-card arrangement, configuration, and deployed methodologies that may influence the overall reset time MUST be listed. (Refer to the additional factors listed in Section 3).
また、全体的なリセット時間に影響を与える可能性がDUT（被試験デバイス）またはSUT（システムテスト中）とテストベッドのプロビジョニング、ポートおよびラインカードの配置、構成、および展開方法が記載されている必要があり。 （セクション3に記載されている追加の因子を参照）。
The reporting of results MUST regard repeatability considerations from Section 4 of [RFC2544]. It is RECOMMENDED to perform multiple trials and report average results.
結果の報告は、[RFC2544]のセクション4から再現性の考慮を考えてしなければなりません。複数の臨床試験を行い、平均の結果を報告することをお勧めします。
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 [RFC2119]. 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.
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますBCP 14、RFC 2119 [RFC2119]に記載されているように解釈されます。 RFC 2119は、可能な限り明確な標準化過程ドキュメントの意図を支援するために、これらのキーワードの使用を定義します。この文書は、これらのキーワードを使用していますが、この文書は標準トラック文書ではありません。
Tests SHOULD first be performed such that the forwarding state re-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), Address Resolution Protocol (ARP), PPP Control Protocols, etc.). The considerations in this section apply.
試験は、最初の転送状態の再確立（すなわち、静的アドレス解決、ルーティングおよび転送構成ではなく、動的プロトコルを使用して）外部ソースから独立しているように実行されるべきです。しかし、試験は続いて（例えば、動的インテリアゲートウェイプロトコル（IGP）、等を解決プロトコル（ARP）、PPP制御プロトコルを、アドレス）転送状態が依存するダイナミックプロトコルを用いて行うことができます。このセクションの考慮事項が適用されます。
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 and (b) document and report any factors that may influence the overall time after reset/convergence.
異なるDUTのセットをベンチマークしながら一貫性と公平性を提供するために、ネットワークテスター/オペレータは、（a）は、テストおよび（B）文書中に同一の制御およびデータプレーン情報を使用して、リセット後の全体的な時間に影響を及ぼし得る任意の因子を報告しなければなりません/収束。
Some of these factors include the following:
これらの要因のいくつかは、次のものがあります。
1. Type of reset - hardware (line-card crash, etc.) versus software (protocol reset, process crash, etc.) or even complete power failures
1リセットの種類 - （等プロトコルリセット、プロセスクラッシュ）ソフトウェアに対するハードウェア（ラインカードクラッシュなど）あるいは完全な停電
10. Performance - Redundancy strategy deployed for route processors and line cards
10.パフォーマンス - ルートプロセッサとラインカードの展開冗長性戦略
11. Performance - Interface encapsulation as well as achievable throughput [RFC2544]
11.パフォーマンス - インタフェースのカプセル化、並びに達成可能なスループット[RFC2544]
12. Any other internal or external factor that may influence reset time after a hardware or software reset
12.ハードウェアまたはソフトウェアリセット後のリセット時間に影響を及ぼし得る任意の他の内部または外部要因
The reset time is one of the key characterization results reported after each test run. While the reset time during a reset test event may be zero, there may still be effects on traffic, such as transient delay variation or increased latency. However, that is not covered and is deemed outside the scope of this document. In this case, only "no loss" is reported.
リセット時間は、各テストの実行後に報告されたキー特性評価結果の一つです。リセットテストイベント時のリセット時間がゼロであってもよいが、それでも、このような過渡的な遅延変動や待ち時間の増加などのトラフィックへの影響があるかもしれません。しかし、それはカバーされていないと、この文書の範囲外であると考えられます。この場合、唯一の「損失」は報告されません。
This section contains descriptions of the tests that are related to the characterization of the time needed for DUTs (Devices Under Test) or SUTs (Systems Under Test) to recover from a reset. There are three types of resets considered in this document:
このセクションでは、リセットから回復するためのDUT（被試験デバイス）またはのSUT（テスト対象システム）のために必要な時間の特性に関連したテストの記述が含まれています。この文書で考慮リセットの3つのタイプがあります。
Different types of resets potentially have a different impact on the forwarding behavior of the device. As an example, a software reset (of a routing process) might not result in forwarding interruption, whereas a hardware reset (of a line card) most likely will.
リセットの異なるタイプは、潜在的にデバイスの転送動作に異なる影響を与えます。一例として、（ルーティング処理の）ソフトウェアリセットは、転送中断をもたらさないかもしれない（ラインカードの）ハードウェアリセット可能性が最も高い意志一方。
Section 4.1 describes various hardware resets, whereas Section 4.2 describes various software resets. Additionally, Section 4.3 describes power interruption tests. These sections define and characterize these resets.
4.2節は、様々なソフトウェア・リセットを説明し、一方、4.1節では、さまざまなハードウェアリセットを説明します。また、4.3節では停電テストを記述します。ここでは、これらのリセットを定義し、特徴づけます。
Additionally, since device-specific implementations may vary for hardware and software type resets, it is desirable to classify each test case as "REQUIRED" or "OPTIONAL".
デバイス固有の実装は、ハードウェアとソフトウェアの種類をリセットするために変えることができるので、また、「必須」または「任意」として、各テストケースを分類することが望ましいです。
A hardware reset test is a test designed to characterize the time it takes a DUT to recover from a hardware reset.
ハードウェアリセットテストは、ハードウェア・リセットから回復するためにDUTにかかる時間を特徴づけるために設計されたテストです。
A hardware reset generally involves the re-initialization of one or more physical components in the DUT, but not the entire DUT.
ハードウェアリセットは、一般にDUT内の1つまたは複数の物理的なコンポーネントの再初期化ではなく、全体のDUTを含みます。
A hardware reset is executed by the operator, for example, by physical removal of a hardware component, by pressing a reset button for the component, or by being triggered from the command line interface (CLI).
ハードウェアリセットは、例えば、ハードウェア構成要素を物理的に除去することによって、コンポーネントのリセットボタンを押すことによって、またはコマンドラインインタフェース（CLI）からトリガされることによって、オペレータによって実行されます。
Reset procedures that do not require the physical removal and insertion of a hardware component are RECOMMENDED. These include using the command line interface (CLI) or a physical switch or button. If such procedures cannot be performed (e.g., because of a lack of platform support or because the corresponding test case calls for them), human operation time SHOULD be minimized across different platforms and test cases as much as possible, and variation in human operator time SHOULD also be minimized across different vendors' products as much as practical by having the same person perform the operation and by practicing the operation. Additionally, the time between removal and insertion SHOULD be recorded and reported.
ハードウェアコンポーネントの物理的除去および挿入を必要としないリセット手順が推奨されます。これらは、コマンドラインインタフェース（CLI）または物理的なスイッチまたはボタンを使用することを含みます。このような手順を行うことができない場合（例えば、なぜならプラットフォームのサポートの欠如の対応するテストケースは、彼らのために呼び出すため又は）、人間の動作時間は、異なるプラットフォームとできるだけテストケース、および人間のオペレータの時間のばらつきを横切って最小化されるべきですまた、同じ人が操作を行うことによって、操作を実施することにより実用的な限り多くの異なるベンダーの製品間で最小化されなければなりません。また、削除および挿入の間の時間を記録し、報告する必要があります。
For routers that do not contain separate Routing Processor and Line Card modules, the hardware reset tests are not performed since they are not relevant; instead, the power interruption tests MUST be performed (see Section 4.3) in these cases.
彼らは関係ありませんので、別のルーティング・プロセッサおよびラインカードモジュールが含まれていないルータの場合、ハードウェア・リセット・テストは実行されません。代わりに、停電のテストでは、これらのケースでは（4.3節を参照）を実行しなければなりません。
The Routing Processor (RP) is the DUT module that is primarily concerned with Control Plane functions.
ルーティングプロセッサ（RP）は、制御プレーン機能と主に関するものであるDUTのモジュールです。
Objective
目的
To characterize the time needed for a DUT to recover from a Route Processor hardware reset in a single RP environment.
単一RP環境でのルートプロセッサのハードウェアリセットから回復するDUTに必要な時間を特徴づけるために。
Procedure
手順
First, ensure that the RP is in a permanent state to which it will return after the reset by performing some or all of the following operational tasks: save the current DUT configuration, specify boot parameters, ensure the appropriate software files are available, or perform additional operating system or hardware-related tasks.
まず、RPはそれが次運用タスクの一部またはすべてを実行することにより、リセット後に戻ります先の永続的な状態にあることを確認します、現在のDUTの設定を保存し、ブートパラメータを指定し、適切なソフトウェアファイルが利用可能であることを確認、または実行追加のオペレーティングシステムやハードウェア関連のタスク。
Second, ensure that the DUT is able to forward the traffic for at least 15 seconds before any test activities are performed. The traffic should use the minimum frame size possible on the media used in the testing, and the rate should be sufficient for the DUT to attain the maximum forwarding throughput. This enables a finer granularity in the reset time measurement.
第二に、DUTがすべてのテスト活動が実行される前に、少なくとも15秒間、トラフィックを転送することが可能であることを確認してください。トラフィックは、テストで使用されるメディア上の可能な最小のフレームサイズを使用する必要があり、かつDUTが最大転送スループットを達成するための速度が十分でなければなりません。これはリセット時の測定で、より細かい粒度を可能にします。
Third, perform the Route Processor (RP) hardware reset at this point. This entails, for example, physically removing the RP to later re-insert it or triggering a hardware reset by other means (e.g., command line interface, physical switch, etc.).
第三に、ルートプロセッサ（RP）は、この時点でのハードウェアリセットを実行します。これは、物理的に後でそれを再挿入するためにRPを除去または他の手段（例えば、コマンドラインインタフェース、物理的なスイッチ、など）によりハードウェアリセットをトリガする、例えば、伴います。
Finally, complete the characterization by recording the frame loss or timestamps (as reported by the test tool) and calculating the reset time (as defined in Section 1.3).
最後に、（セクション1.3で定義されるように）フレームの損失又はタイムスタンプを記録する（テストツールによって報告される）及びリセット時間を計算することによって特徴付けを完了します。
Reporting Format
レポーティングフォーマット
The reporting format is defined in Section 1.4.
レポーティング・フォーマットは、セクション1.4で定義されています。
Objective
目的
To characterize the time needed for the "secondary" Route Processor (sometimes referred to as the "backup" RP) of a DUT to become active after a "primary" (or "active") Route Processor hardware reset. This process is often referred to as "RP Switchover". The characterization in this test should be done for the default DUT behavior and, if it exists, for the DUT's non-default configuration that minimizes frame loss.
「二次」ルートプロセッサに必要な時間を特徴付けるために「一次」（または「活性な」）ルートプロセッサのハードウェアリセット後にアクティブになるようにDUTの（時には「バックアップ」RPと呼びます）。このプロセスは、しばしば「RP切り替え」と呼ばれています。このテストでの特性は、フレーム損失を最小化するDUTの非デフォルトの設定のために、それが存在する場合は、デフォルトのDUTの動作のために行われ、しなければなりません。
Procedure
手順
This test characterizes RP Switchover. Many implementations allow for optimized switchover capabilities that minimize the downtime during the actual switchover. This test consists of two sub-cases from a switchover characteristic's standpoint: first, a default behavior (with no switchover-specific configurations) and, potentially second, a non-default behavior with switchover configuration to minimize frame loss. Therefore, the procedures hereby described are executed twice and reported separately.
このテストでは、RPの切り替えを特徴付けます。多くの実装では、実際の切り替え時のダウンタイムを最小限に抑え、最適化の切り替え機能を可能にします。フレーム損失を最小限にするために、潜在的に第二の切り替え構成を有する非デフォルト動作を（NO切り替え固有の構成で）最初、デフォルトの動作と：この試験は、切り替え特性の観点から、二つのサブケースで構成されています。したがって、本明細書に記載された手順を2回実行され、別々に報告しました。
First, ensure that the RPs are in a permanent state such that the secondary RP will be activated to the same state as the active RP by performing some or all of the following operational tasks: save the current DUT configuration, specify boot parameters, ensure the appropriate software files are available, or perform additional operating system or hardware-related tasks.
まず、RPは永久的な状態でセカンダリRPは、以下の運用タスクの一部またはすべてを実行することにより、アクティブRPと同じ状態に活性化されるようなものであることを確認します。確実に、ブートパラメータを指定して、現在のDUTの設定を保存適切なソフトウェアファイルが入手可能であるか、または追加のオペレーティングシステムやハードウェア関連のタスクを実行します。
Second, ensure that the DUT is able to forward the traffic for at least 15 seconds before any test activities are performed. The traffic should use the minimum frame size possible on the media used in the testing, and the rate should be sufficient for the DUT to attain the maximum forwarding throughput. This enables a finer granularity in the reset time measurement.
第二に、DUTがすべてのテスト活動が実行される前に、少なくとも15秒間、トラフィックを転送することが可能であることを確認してください。トラフィックは、テストで使用されるメディア上の可能な最小のフレームサイズを使用する必要があり、かつDUTが最大転送スループットを達成するための速度が十分でなければなりません。これはリセット時の測定で、より細かい粒度を可能にします。
Third, perform the primary Route Processor (RP) hardware reset at this point. This entails, for example, physically removing the RP or triggering a hardware reset by other means (e.g., command line interface, physical switch, etc.). It is up to the operator to decide whether or not the primary RP needs to be re-inserted after a grace period.
第三に、この時点ではプライマリルートプロセッサ（RP）ハードウェアリセットを実行します。これは、物理的にRPを除去または他の手段（例えば、コマンドラインインタフェース、物理的なスイッチ、など）によりハードウェアリセットをトリガする、例えば、伴います。これは、プライマリRPは、猶予期間後に再挿入する必要があるかどうかを決定するためにオペレータに任されています。
Finally, complete the characterization by recording the frame loss or timestamps (as reported by the test tool) and calculating the reset time (as defined in Section 1.3).
最後に、（セクション1.3で定義されるように）フレームの損失又はタイムスタンプを記録する（テストツールによって報告される）及びリセット時間を計算することによって特徴付けを完了します。
Reporting Format
レポーティングフォーマット
The reset results are potentially reported twice, one for the default switchover behavior (i.e., the DUT without any switchover-specific enhanced configuration) and the other for the switchover-specific behavior if it exists (i.e., the DUT configured for optimized switchover capabilities that minimize the downtime during the actual switchover).
リセットの結果は、潜在的にデフォルトの切り替え動作のための1つ、二回報告されている（すなわち、任意の切り替え固有のエンハンスド・コンフィギュレーションのないDUT）と、それが存在する場合は、スイッチオーバー固有の動作（のための他のすなわち、最適化された切替機能用に設定さDUTこと）実際の切り替え時のダウンタイムを最小限に抑えます。
The reporting format is defined in Section 1.4 and also includes any specific redundancy scheme in place.
レポーティング・フォーマットは、セクション1.4で定義され、また、代わりに任意の特定の冗長方式を備えています。
The Line Card (LC) is the DUT component that is responsible for packet forwarding.
ラインカード（LC）は、パケット転送を担当してDUTのコンポーネントです。
Objective
目的
To characterize the time needed for a DUT to recover from a line-card removal and insertion event.
ラインカードの取り外しと挿入イベントから回復するDUTに必要な時間を特徴づけるために。
Procedure
手順
For this test, the line card that is being hardware-reset MUST be on the forwarding path, and all destinations MUST be directly connected.
この試験のために、ハードウェアリセットされているラインカードは、転送パス上にある必要があり、すべての宛先が直接接続されなければなりません。
First, complete some or all of the following operational tasks: save the current DUT configuration, specify boot parameters, ensure the appropriate software files are available, or perform additional operating system or hardware-related tasks.
適切なソフトウェアファイルが入手可能であるか、または追加のオペレーティングシステムやハードウェア関連のタスクを実行することを確認、ブートパラメータを指定して、現在のDUTの設定を保存します。まず、以下の運用タスクの一部またはすべてを完了します。
Second, ensure that the DUT is able to forward the traffic for at least 15 seconds before any test activities are performed. The traffic should use the minimum frame size possible on the media used in the testing, and the rate should be sufficient for the DUT to attain the maximum forwarding throughput. This enables a finer granularity in the reset time measurement.
第二に、DUTがすべてのテスト活動が実行される前に、少なくとも15秒間、トラフィックを転送することが可能であることを確認してください。トラフィックは、テストで使用されるメディア上の可能な最小のフレームサイズを使用する必要があり、かつDUTが最大転送スループットを達成するための速度が十分でなければなりません。これはリセット時の測定で、より細かい粒度を可能にします。
Third, perform the Line Card (LC) hardware reset at this point. This entails, for example, physically removing the LC to later re-insert it or triggering a hardware reset by other means (e.g., CLI, physical switch, etc.).
第三に、この時点で、ラインカード（LC）ハードウェアリセットを実行します。これは、物理的に後でそれを再挿入するためにLCを除去または他の手段（例えば、CLI、物理的なスイッチ、など）によりハードウェアリセットをトリガする、例えば、伴います。
Finally, complete the characterization by recording the frame loss or timestamps (as reported by the test tool) and calculating the reset time (as defined in Section 1.3).
最後に、（セクション1.3で定義されるように）フレームの損失又はタイムスタンプを記録する（テストツールによって報告される）及びリセット時間を計算することによって特徴付けを完了します。
Reporting Format
レポーティングフォーマット
The reporting format is defined in Section 1.4.
レポーティング・フォーマットは、セクション1.4で定義されています。
A software reset test characterizes the time needed for a DUT to recover from a software reset.
ソフトウェア・リセット・テストは、ソフトウェアリセットから回復するためにDUTに必要な時間を特徴付けます。
In contrast to a hardware reset, a software reset involves only the re-initialization of the execution, data structures, and partial state within the software running on the DUT module(s).
ハードウェアリセットとは対照的に、ソフトウェアリセットは、DUTのモジュール（複数可）上で動作するソフトウェア内での実行、データ構造、および部分の状態のみ再初期化することを含みます。
A software reset is initiated, for example, from the DUT's CLI.
ソフトウェアリセットは、DUTのCLIから、例えば、開始されます。
Objective
目的
To characterize the time needed for a DUT to recover from an operating system (OS) software reset.
オペレーティングシステム（OS）ソフトウェアリセットから回復するDUTに必要な時間を特徴づけるために。
Procedure
手順
First, complete some or all of the following operational tasks: save the current DUT configuration, specify software boot parameters, ensure the appropriate software files are available, or perform additional operating system tasks.
適切なソフトウェアファイルが入手可能であるか、または追加のオペレーティングシステムのタスクを実行することを確認、ソフトウェアのブートパラメータを指定して、現在のDUTの設定を保存します。まず、以下の運用タスクの一部またはすべてを完了します。
Second, ensure that the DUT is able to forward the traffic for at least 15 seconds before any test activities are performed. The traffic should use the minimum frame size possible on the media used in the testing, and the rate should be sufficient for the DUT to attain the maximum forwarding throughput. This enables a finer granularity in the reset time measurement.
第二に、DUTがすべてのテスト活動が実行される前に、少なくとも15秒間、トラフィックを転送することが可能であることを確認してください。トラフィックは、テストで使用されるメディア上の可能な最小のフレームサイズを使用する必要があり、かつDUTが最大転送スループットを達成するための速度が十分でなければなりません。これはリセット時の測定で、より細かい粒度を可能にします。
Third, trigger an operating system re-initialization in the DUT by operational means such as use of the DUT's CLI or other management interface.
第三に、こうしたDUTのCLIまたは他の管理インターフェイスの使用などの操作によって、DUTにおけるオペレーティングシステムの再初期化をトリガーします。
Finally, complete the characterization by recording the frame loss or timestamps (as reported by the test tool) and calculating the reset time (as defined in Section 1.3).
最後に、（セクション1.3で定義されるように）フレームの損失又はタイムスタンプを記録する（テストツールによって報告される）及びリセット時間を計算することによって特徴付けを完了します。
Reporting Format
レポーティングフォーマット
The reporting format is defined in Section 1.4.
レポーティング・フォーマットは、セクション1.4で定義されています。
Objective
目的
To characterize the time needed for a DUT to recover from a software process reset.
ソフトウェアプロセスのリセットから回復するDUTに必要な時間を特徴づけるために。
Such a time period may depend upon the number and types of processes running in the DUT and which ones are tested. Different implementations of forwarding devices include various common processes. A process reset should be performed only in the processes most relevant to the tester and most impactful to forwarding.
そのような期間は、DUTで実行されているプロセスの数及びタイプに依存し、どれがテストされてもよいです。転送装置の様々な実装は、種々の一般的なプロセスを含みます。プロセスリセットのみテスタに最も関連すると転送に最もインパクトの過程で行われるべきです。
Procedure
手順
First, complete some or all of the following operational tasks: save the current DUT configuration, specify software parameters or environmental variables, or perform additional operating system tasks.
まず、以下の運用タスクの一部またはすべてを完了してください、現在のDUTの設定を保存し、ソフトウェアのパラメータや環境変数を指定する、または追加のオペレーティングシステムのタスクを実行します。
Second, ensure that the DUT is able to forward the traffic for at least 15 seconds before any test activities are performed. The traffic should use the minimum frame size possible on the media used in the testing, and the rate should be sufficient for the DUT to attain the maximum forwarding throughput. This enables a finer granularity in the reset time measurement.
第二に、DUTがすべてのテスト活動が実行される前に、少なくとも15秒間、トラフィックを転送することが可能であることを確認してください。トラフィックは、テストで使用されるメディア上の可能な最小のフレームサイズを使用する必要があり、かつDUTが最大転送スループットを達成するための速度が十分でなければなりません。これはリセット時の測定で、より細かい粒度を可能にします。
Third, trigger a process reset for each process running in the DUT and considered for testing from a management interface (e.g., by means of the CLI, etc.).
第三に、各プロセスがDUTで実行し、管理インタフェース（例えば、CLIにより、等）からの試験のために考慮するためのプロセスのリセットをトリガします。
Finally, complete the characterization by recording the frame loss or timestamps (as reported by the test tool) and calculating the reset time (as defined in Section 1.3).
最後に、（セクション1.3で定義されるように）フレームの損失又はタイムスタンプを記録する（テストツールによって報告される）及びリセット時間を計算することによって特徴付けを完了します。
Reporting Format
レポーティングフォーマット
The reporting format is defined in Section 1.4 and is used for each process running in the DUT and tested. Given the implementation nature of this test, details of the actual process tested should be included along with the statement.
レポーティングフォーマットはセクション1.4で定義され、DUTで実行中の各プロセスのために使用され、テストされています。このテストの実施性質を考えると、テストした実際の処理の詳細については、文と一緒に含まれるべきです。
"Power interruption" refers to the complete loss of power on the 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 components, and is characterized by the re-initialization of all hardware and software in the DUT.
「停電」DUTの電源の完全な喪失を指します。これは、DUT又はその構成要素への電力供給の喪失によってトリガハードウェアリセットの特殊な場合とみなすことができ、DUT内のすべてのハードウェアおよびソフトウェアの再初期化することを特徴とします。
Objective
目的
To characterize the time needed for a DUT to recover from a complete loss of electric power or complete power interruption. This test simulates a complete power failure or outage and should be indicative of the DUT/SUT's behavior during such event.
電力または完全な停電の完全な損失から回復するためにDUTに必要な時間を特徴づけるために。このテストは、完全な電源障害や停電をシミュレートし、このようなイベントの間にDUT / SUTの挙動を示すべきです。
Procedure
手順
First, ensure that the entire DUT is at a permanent state to which it will return after the power interruption by performing some or all of the following operational tasks: save the current DUT configuration, specify boot parameters, ensure the appropriate software files are available, or perform additional operating system or hardware-related tasks.
まず、全体のDUTが、それは以下の運用タスクの一部またはすべてを実行することにより、停電後に戻ります先の永久的な状態であることを確認します、現在のDUTの設定を保存し、ブートパラメータを指定し、適切なソフトウェアファイルが使用可能であることを確認または追加のオペレーティングシステムやハードウェア関連のタスクを実行します。
Second, ensure that the DUT is able to forward the traffic for at least 15 seconds before any test activities are performed. The traffic should use the minimum frame size possible on the media used in the testing, and the rate should be sufficient for the DUT to attain the maximum forwarding throughput. This enables a finer granularity in the reset time measurement.
第二に、DUTがすべてのテスト活動が実行される前に、少なくとも15秒間、トラフィックを転送することが可能であることを確認してください。トラフィックは、テストで使用されるメディア上の可能な最小のフレームサイズを使用する必要があり、かつDUTが最大転送スループットを達成するための速度が十分でなければなりません。これはリセット時の測定で、より細かい粒度を可能にします。
Third, interrupt the power (AC or DC) that feeds the corresponding DUT's power supplies at this point. This entails, for example, physically removing the power supplies in the DUT to later re-insert them or simply disconnecting or switching off their power feeds (AC or DC, as applicable). The actual power interruption should last at least 15 seconds.
第三に、この時点で対応するDUTの電源を供給電源（ACまたはDC）を割り込みます。これは、物理的にそれらを後で再挿入するためにDUTに電源を削除または単に（必要に応じて、ACまたはDC）切断又はそれらの電力フィードをオフ、例えば、伴います。実際の停電は、少なくとも15秒続く必要があります。
Finally, complete the characterization by recording the frame loss or timestamps (as reported by the test tool) and calculating the reset time (as defined in Section 1.3).
最後に、（セクション1.3で定義されるように）フレームの損失又はタイムスタンプを記録する（テストツールによって報告される）及びリセット時間を計算することによって特徴付けを完了します。
For easier comparison with other testing, 15 seconds are removed from the reported reset time.
他のテストとの比較を容易にするために、15秒が報告されたリセット時間から削除されます。
Reporting Format
レポーティングフォーマット
The reporting format is defined in Section 1.4.
レポーティング・フォーマットは、セクション1.4で定義されています。
Benchmarking activities, as described in this document, are limited to technology characterization using controlled stimuli in a laboratory environment, with dedicated address space and the constraints specified in the sections above.
この文書で説明するような活動をベンチマーク、専用のアドレス空間と上記のセクションで指定された制約で、実験室環境で制御刺激を使用して技術の特性に限定されています。
The benchmarking network topology will be an independent test setup and MUST NOT be connected to devices that may forward the test traffic into a production network or misroute traffic to the test management network.
ベンチマークネットワークトポロジは、独立したテストのセットアップになり、テスト管理ネットワークへの生産ネットワークやmisrouteトラフィックにテストトラフィックを転送することができるデバイスに接続しないでください。
Furthermore, benchmarking is performed on a "black-box" basis, relying solely on measurements observable externally to the DUT/SUT.
また、ベンチマークは、外部DUT / SUTに観察測定値にのみ依存する、「ブラックボックス」に基づいて行われます。
Special capabilities SHOULD NOT exist in the DUT/SUT specifically for benchmarking purposes. Any implications for network security arising from the DUT/SUT SHOULD be identical in the lab and in production networks.
特別な機能は、ベンチマークの目的のために特別に/ DUTにSUT存在してはなりません。 DUT / SUTに起因するネットワークセキュリティのための任意の影響はラボで、生産ネットワークで同一である必要があります。
There are no specific security considerations within the scope of this document.
この文書の範囲内には特定のセキュリティの考慮事項はありません。
The authors would like to thank Ron Bonica, who motivated us to write this document. The authors would also like to thank Al Morton, Andrew Yourtchenko, David Newman, John E. Dawson, Timmons C. Player, Jan Novak, Steve Maxwell, Ilya Varlashkin, and Sarah Banks for providing thorough review, useful suggestions, and valuable input.
著者は、この文書を書くために私たちをやる気ロンBonicaを、感謝したいと思います。著者らはまた、徹底的な見直し、有益な提案、貴重な入力を提供するためのアル・モートン、アンドリューYourtchenko、デヴィッド・ニューマン、ジョン・E.ドーソン、ティモンズC.プレーヤー、ジャン・ノヴァク、スティーブ・マックスウェル、イリヤVarlashkin、とサラ銀行に感謝したいと思います。
[RFC1242] Bradner, S., "Benchmarking Terminology for Network Interconnection Devices", RFC 1242, July 1991.
[RFC1242]ブラドナーの、S.、 "ネットワーク相互接続デバイスのためのベンチマーキング用語"、RFC 1242、1991年7月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2544] Bradner, S. and J. McQuaid, "Benchmarking Methodology for Network Interconnect Devices", RFC 2544, March 1999.
、RFC 2544、1999年3月 "ネットワーク相互接続デバイスのためのベンチマーキング方法論" [RFC2544]ブラドナー、S.とJ. McQuaid、。
[IGPConv] Poretsky, S., Imhoff, B., and K. Michielsen, "Benchmarking Methodology for Link-State IGP Data Plane Route Convergence", Work in Progress, February 2011.
[IGPConv] Poretsky、S.、Imhoff氏、B.、およびK. Michielsen、 "リンクステートIGPデータプレーンのルートコンバージェンスのためのベンチマーキング方法論"、進歩、2011年2月での作業。
[RFC5180] Popoviciu, C., Hamza, A., Van de Velde, G., and D. Dugatkin, "IPv6 Benchmarking Methodology for Network Interconnect Devices", RFC 5180, May 2008.
[RFC5180]、RFC 5180、2008年5月 "ネットワーク相互接続デバイスのIPv6ベンチマーキング方法論" Popoviciu、C.、ハムザ、A.、ヴァン・デ・ヴェルデ、G.、およびD. Dugatkin、。
[RFC5695] Akhter, A., Asati, R., and C. Pignataro, "MPLS Forwarding Benchmarking Methodology for IP Flows", RFC 5695, November 2009.
[RFC5695] Akhter、A.、Asati、R.、およびC. Pignataroは、RFC 5695、2009年11月、 "IPのためのMPLSフォワーディングベンチマーキング方法論は、フロー"。
Authors' Addresses
著者のアドレス
Rajiv Asati Cisco Systems 7025-6 Kit Creek Road Research Triangle Park, NC 27709 USA
ラジブAsatiシスコシステムズ7025から6キットクリーク道路リサーチトライアングルパーク、NC 27709 USA
EMail: rajiva@cisco.com
メールアドレス：rajiva@cisco.com
Carlos Pignataro Cisco Systems 7200-12 Kit Creek Road Research Triangle Park, NC 27709 USA
カルロスPignataroシスコシステムズ7200から12キットクリーク道路リサーチトライアングルパーク、NC 27709 USA
EMail: cpignata@cisco.com
メールアドレス：cpignata@cisco.com
Fernando Calabria Cisco Systems 7200-12 Kit Creek Road Research Triangle Park, NC 27709 USA
フェルナンド・カラブリアシスコシステムズ7200から12キットクリーク道路リサーチトライアングルパーク、NC 27709 USA
EMail: fcalabri@cisco.com
メールアドレス：fcalabri@cisco.com
Cesar Olvera Morales Consulintel Joaquin Turina, 2 Pozuelo de Alarcon, Madrid, E-28224 Spain
セザールオルベラモラレスConsulintelホアキン・トゥリーナ、2ポズエロデアラルコン、マドリッド、E-28224スペイン
EMail: cesar.olvera@consulintel.es
メールアドレス：cesar.olvera@consulintel.es