[要約] RFC 6201は、デバイスのリセット特性に関する情報を提供するためのものです。目的は、デバイスのリセット動作を正確に特徴づけることで、ネットワークデバイスの信頼性と互換性を向上させることです。
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によって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補者ではありません。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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2011 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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. フレームロスメソッド - この方法では、失われたフレームの数を監視するためにテストツール機能が必要です。この方法では、提供されたストリームレート（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. タイムスタンプ方法 - この方法では、各フレームをタイムスタンプするテストツール機能が必要です。この方法では、テストツールのタイムスタンプが各フレームを送信し、受信したフレームのタイムスタンプを監視します。テスト中、テストツールは、リセット中断の前に最後に受信されたフレームのタイムスタンプ（タイムスタンプA）と、中断が停止した後の最初のフレームのタイムスタンプ（タイムスタンプB）を記録します。タイムスタンプ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）物理リンクのステータスがアップしている場合にのみフレームを送信できます。つまり、特定のテストツール機能が使用する方法を決定する場合があります。テストツールがその機能に基づいて両方の方法をサポートする場合、テスター/オペレーターはより精度を提供するものを使用する必要があります。
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
スループットフレームあたりのフレームと1秒あたりのビット
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.
インターフェイスの封じ込め。イーサネット、イーサネット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.
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、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.
一貫性と公平性を提供するために、さまざまなDUTSのセットをベンチマークしながら、ネットワークテスター/オペレーターは（a）テスト中に同一のコントロールとデータプレーン情報を使用する必要があります。/収束。
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. リセットの種類 - ハードウェア（ラインカードクラッシュなど）対ソフトウェア（プロトコルリセット、プロセスクラッシュなど）、または完全な電力障害
2. Manual versus automatic reset
2. 手動リセットと自動リセット
3. Scheduled versus non-scheduled reset
3. スケジュールされたものと非スケジュールリセット
4. Local versus remote reset
4. ローカルとリモートリセット
5. Scale - Number of line cards present versus in use
5. スケール - 使用中のラインカード数と使用中
6. Scale - Number of physical and logical interfaces
6. スケール - 物理的および論理的なインターフェイスの数
7. Scale - Number of routing protocol instances
7. スケール - ルーティングプロトコルインスタンスの数
8. Scale - Number of routing table entries
8. スケール - ルーティングテーブルエントリの数
9. Scale - Number of route processors available 10. Performance - Redundancy strategy deployed for route processors and line cards
9. スケール - 利用可能なルートプロセッサの数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.
リセット時間は、各テスト実行後に報告された重要な特性評価結果の1つです。リセットテストイベント中のリセット時間はゼロになる可能性がありますが、一時的な遅延変動やレイテンシの増加など、トラフィックに影響がある場合があります。ただし、それはカバーされておらず、このドキュメントの範囲外であると見なされます。この場合、「損失なし」のみが報告されます。
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（テスト中のデバイス）またはSUTS（テスト対象のシステム）に必要な時間の特性評価に関連するテストの説明が含まれています。このドキュメントでは、3種類のリセットが考慮されています。
1. Hardware resets
1. ハードウェアリセット
2. Software resets
2. ソフトウェアリセット
3. Power interruption
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.1では、さまざまなハードウェアリセットについて説明しますが、セクション4.2ではさまざまなソフトウェアリセットについて説明します。さらに、セクション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.
DUTが単一のRP環境でルートプロセッサハードウェアリセットから回復するために必要な時間を特徴付ける。
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スイッチオーバーを特徴付けます。多くの実装により、実際のスイッチオーバー中のダウンタイムを最小限に抑える最適化されたスイッチオーバー機能が可能になります。このテストは、スイッチオーバー特性の立場からの2つのサブケースで構成されています。1つ目は、デフォルトの動作（スイッチオーバー固有の構成なし）と、潜在的には、フレーム損失を最小限に抑えるスイッチオーバー構成を備えた非デフォルト動作です。したがって、ここで説明する手順は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).
リセットの結果は、デフォルトのスイッチオーバー動作（つまり、スイッチオーバー固有の強化された構成のないDUT）の場合は2回報告されます。実際のスイッチオーバー中のダウンタイムを最小限に抑えます）。
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.
DUTがオペレーティングシステム（OS）ソフトウェアリセットから回復するために必要な時間を特徴付ける。
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またはその他の管理インターフェイスの使用などの運用手段により、OPTINATIONシステムの運用手段によりオペレーティングシステムの再目的化をトリガーします。
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全体が、次の運用タスクの一部またはすべてを実行することにより、停電後に戻る永続的な状態にあることを確認します。または、追加のオペレーティングシステムまたはハードウェア関連のタスクを実行します。
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.
ベンチマークネットワークトポロジは、独立したテストセットアップとなり、テストトラフィックを生産ネットワークに転送したり、トラフィックをテスト管理ネットワークに誤って転送したりするデバイスに接続してはなりません。
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.
著者は、この文書を書くように私たちに動機付けたロン・ボニャに感謝したいと思います。著者はまた、徹底的なレビュー、有用な提案、貴重なインプットを提供してくれたAl Morton、Andrew Yourtchenko、David Newman、David Newman、John E. Dawson、Jan Novak、Steve Maxwell、Ilya Varlashkin、Sarah Banksに感謝します。
[RFC1242] Bradner, S., "Benchmarking Terminology for Network Interconnection Devices", RFC 1242, July 1991.
[RFC1242] Bradner、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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2544] Bradner, S. and J. McQuaid, "Benchmarking Methodology for Network Interconnect Devices", RFC 2544, March 1999.
[RFC2544] Bradner、S。およびJ. McQuaid、「ネットワーク相互接続デバイスのベンチマーク方法論」、RFC 2544、1999年3月。
[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] Popoviciu、C.、Hamza、A.、Van de Velde、G。、およびD. Dugatkin、「ネットワーク相互接続デバイスのIPv6ベンチマーク方法」、RFC 5180、2008年5月。
[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、「IPフローのMPLS転送方法論」、RFC 5695、2009年11月。
Authors' Addresses
著者のアドレス
Rajiv Asati Cisco Systems 7025-6 Kit Creek Road Research Triangle Park, NC 27709 USA
Rajiv Asati Cisco Systems 7025-6 Kit Creek Road Research Triangle Park、NC 27709 USA
EMail: rajiva@cisco.com
Carlos Pignataro Cisco Systems 7200-12 Kit Creek Road Research Triangle Park, NC 27709 USA
Carlos Pignataro Cisco Systems 7200-12 Kit Creek Road Research Triangle Park、NC 27709 USA
EMail: cpignata@cisco.com
Fernando Calabria Cisco Systems 7200-12 Kit Creek Road Research Triangle Park, NC 27709 USA
Fernando Calabria Cisco Systems 7200-12 Kit Creek Road Research Triangle Park、NC 27709 USA
EMail: fcalabri@cisco.com
Cesar Olvera Morales Consulintel Joaquin Turina, 2 Pozuelo de Alarcon, Madrid, E-28224 Spain
Cesar Olvera Morales Consulintel Joaquin Turina、2 Pozuelo de Alarcon、マドリード、E-28224スペイン
EMail: cesar.olvera@consulintel.es