[要約] RFC 7654は、In-Service Software Upgrade（ISSU）のベンチマーク方法論を提供しています。このRFCの目的は、ISSUのパフォーマンス評価と比較を可能にするための一貫した方法論を提供することです。
Internet Engineering Task Force (IETF) S. Banks
Request for Comments: 7654 VSS Monitoring
Category: Informational F. Calabria
ISSN: 2070-1721 Cisco Systems
G. Czirjak
R. Machat
Juniper Networks
October 2015
Benchmarking Methodology for In-Service Software Upgrade (ISSU)
インサービスソフトウェアアップグレード（ISSU）のベンチマーク手法
Abstract
概要
Modern forwarding devices attempt to minimize any control- and data-plane disruptions while performing planned software changes by implementing a technique commonly known as In-Service Software Upgrade (ISSU). This document specifies a set of common methodologies and procedures designed to characterize the overall behavior of a Device Under Test (DUT), subject to an ISSU event.
最新の転送デバイスは、一般にインサービスソフトウェアアップグレード（ISSU）と呼ばれる技術を実装することにより、計画されたソフトウェア変更を実行しながら、コントロールプレーンとデータプレーンの中断を最小限に抑えようとします。このドキュメントでは、ISSUイベントの対象となるテスト対象デバイス（DUT）の全体的な動作を特徴付けるために設計された一連の一般的な方法と手順を指定します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
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（Internet Engineering Task Force）の製品です。これは、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/rfc7654.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7654で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2015 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文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................3
2. Conventions Used in This Document ...............................4
3. Generic ISSU Process, Phased Approach ...........................4
3.1. Software Download ..........................................5
3.2. Software Staging ...........................................6
3.3. Upgrade Run ................................................6
3.4. Upgrade Acceptance .........................................7
4. Test Methodology ................................................7
4.1. Test Topology ..............................................7
4.2. Load Model .................................................8
5. ISSU Test Methodology ...........................................9
5.1. Pre-ISSU Recommended Verifications .........................9
5.2. Software Staging ...........................................9
5.3. Upgrade Run ...............................................10
5.4. Post-ISSU Verification ....................................11
5.5. ISSU under Negative Stimuli ...............................12
6. ISSU Abort and Rollback ........................................12
7. Final Report: Data Presentation and Analysis ...................13
7.1. Data Collection Considerations ............................14
8. Security Considerations ........................................15
9. References .....................................................15
9.1. Normative References ......................................15
9.2. Informative References ....................................16
Acknowledgments ...................................................16
Authors' Addresses ................................................16
As required by most Service Provider (SP) network operators, ISSU functionality has been implemented by modern forwarding devices to upgrade or downgrade from one software version to another with a goal of eliminating the downtime of the router and/or the outage of service. However, it is noted that while most operators desire complete elimination of downtime, minimization of downtime and service degradation is often the expectation.
ほとんどのサービスプロバイダー（SP）ネットワークオペレーターが必要とするISSU機能は、ルーターのダウンタイムやサービスの停止をなくすことを目的として、あるソフトウェアバージョンから別のソフトウェアバージョンにアップグレードまたはダウングレードする最新の転送デバイスによって実装されています。ただし、ほとんどのオペレーターがダウンタイムの完全な排除を望んでいる一方で、ダウンタイムの最小化とサービスの低下が期待されることが多いことに注意してください。
The ISSU operation may apply in terms of an atomic version change of the entire system software or it may be applied in a more modular sense, such as for a patch or maintenance upgrade. The procedure described herein may be used to verify either approach, as may be supported by the vendor hardware and software.
ISSU操作は、システムソフトウェア全体のアトミックバージョンの変更の観点から適用される場合と、パッチやメンテナンスアップグレードなど、よりモジュール的な意味で適用される場合があります。本書に記載されている手順は、ベンダーのハードウェアおよびソフトウェアによってサポートされているため、どちらのアプローチを検証するためにも使用できます。
In support of this document, the desired behavior for an ISSU operation can be summarized as follows:
このドキュメントをサポートするために、ISSU操作の望ましい動作は次のように要約できます。
- The software is successfully migrated from one version to a successive version or vice versa.
- ソフトウェアは、あるバージョンから次のバージョンに、またはその逆に正常に移行されます。
- There are no control-plane interruptions throughout the process. That is, the upgrade/downgrade could be accomplished while the device remains "in service". It is noted, however, that most service providers will still undertake such actions in a maintenance window (even in redundant environments) to minimize any risk.
- プロセス全体でコントロールプレーンの中断はありません。つまり、デバイスが「稼働中」のままで、アップグレード/ダウングレードを実行できます。ただし、ほとんどのサービスプロバイダーは、リスクを最小限に抑えるために、メンテナンスウィンドウ（冗長環境でも）でこのようなアクションを実行することに注意してください。
- Interruptions to the forwarding plane are minimal to none.
- フォワーディングプレーンへの割り込みはごくわずかです。
- The total time to accomplish the upgrade is minimized, again to reduce potential network outage exposure (e.g., an external failure event might impact the network as it operates with reduced redundancy).
- アップグレードを完了するための合計時間は最小化され、潜在的なネットワーク停止の危険性が減少します（たとえば、外部障害イベントは、冗長性が低下して動作するため、ネットワークに影響を与える可能性があります）。
This document provides a set of procedures to characterize a given forwarding device's ISSU behavior quantitatively, from the perspective of meeting the above expectations.
このドキュメントでは、上記の期待を満たすという観点から、特定の転送デバイスのISSU動作を定量的に特徴付ける一連の手順を説明します。
Different hardware configurations may be expected to be benchmarked, but a typical configuration for a forwarding device that supports ISSU consists of at least one pair of Routing Processors (RPs) that operate in a redundant fashion, and single or multiple forwarding engines (line cards) that may or may not be redundant, as well as fabric cards or other components as applicable. This does not preclude the possibility that a device in question can perform ISSU functions through the operation of independent process components, which may be upgraded without impact to the overall operation of the device. As an example, perhaps the software module involved in SNMP functions can be upgraded without impacting other operations.
ベンチマークの対象となるハードウェア構成はさまざまですが、ISSUをサポートするフォワーディングデバイスの一般的な構成は、冗長方式で動作する少なくとも1対のルーティングプロセッサ（RP）と、単一または複数のフォワーディングエンジン（ラインカード）で構成されます。冗長性がある場合もない場合もあり、ファブリックカードやその他のコンポーネントも適宜あります。これは、問題のデバイスが独立したプロセスコンポーネントの動作を通じてISSU機能を実行できる可能性を排除するものではなく、デバイスの全体的な動作に影響を与えることなくアップグレードできます。たとえば、SNMP機能に関連するソフトウェアモジュールは、他の操作に影響を与えることなくアップグレードできます。
The concept of a multi-chassis deployment may also be characterized by the current set of proposed methodologies, but the implementation-specific details (i.e., process placement and others) are beyond the scope of the current document.
マルチシャーシ展開のコンセプトは、現在提案されている方法論のセットによっても特徴付けられますが、実装固有の詳細（つまり、プロセスの配置など）は、現在のドキュメントの範囲を超えています。
Since most modern forwarding devices, where ISSU would be applicable, do consist of redundant RPs and hardware-separated control-plane and data-plane functionality, this document will focus on methodologies that would be directly applicable to those platforms. It is anticipated that the concepts and approaches described herein may be readily extended to accommodate other device architectures as well.
ISSUを適用できる最新の転送デバイスは、冗長RPとハードウェアで分離されたコントロールプレーンおよびデータプレーンの機能で構成されているため、このドキュメントでは、これらのプラットフォームに直接適用できる方法に焦点を当てます。本明細書で説明される概念およびアプローチは、他のデバイスアーキテクチャにも対応するように容易に拡張できることが予想される。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [RFC2119]で説明されているように解釈されます。
In this document, these words will appear with that interpretation only when in ALL CAPS. Lowercase uses of these words are not to be interpreted as carrying the significance of RFC 2119.
このドキュメントでは、これらの単語はすべて大文字の場合にのみその解釈で表示されます。これらの単語の小文字の使用は、RFC 2119の重要性を伴うものとして解釈されるべきではありません。
ISSU may be viewed as the behavior of a device when exposed to a planned change in its software functionality. This may mean changes to the core operating system, separate processes or daemons, or even firmware logic in programmable hardware devices (e.g., Complex Programmable Logic Device (CPLD) or Field-Programmable Gate Array (FPGA)). The goal of an ISSU implementation is to permit such actions with minimal or no disruption to the primary operation of the device in question.
ISSUは、ソフトウェア機能の計画的な変更にさらされたときのデバイスの動作と見なされる場合があります。これは、コアオペレーティングシステム、個別のプロセスまたはデーモン、またはプログラム可能なハードウェアデバイス（例：Complex Programmable Logic Device（CPLD）またはField-Programmable Gate Array（FPGA））のファームウェアロジックへの変更を意味する場合があります。 ISSUの実装の目的は、問題のデバイスの主要な動作をほとんどまたはまったく中断することなく、そのようなアクションを許可することです。
ISSU may be user initiated through direct interaction with the device or activated through some automated process on a management system or even on the device itself. For the purposes of this document, we will focus on the model where the ISSU action is initiated by direct user intervention.
ISSUは、デバイスとの直接の対話を通じてユーザーが開始するか、管理システムまたはデバイス自体の自動化されたプロセスによってアクティブ化できます。このドキュメントでは、ISSUアクションがユーザーの直接介入によって開始されるモデルに焦点を当てます。
The ISSU process can be viewed as a series of different phases or activities, as defined below. For each of these phases, the test operator must record the outcome as well as any relevant observations (defined further in the present document). Note that, a given vendor implementation may or may not permit the abortion of the in-progress ISSU at particular stages. There may also be certain restrictions as to ISSU availability given certain functional configurations (for example, ISSU in the presence of Bidirectional Failure Detection (BFD) [RFC5880] may not be supported). It is incumbent upon the test operator to ensure that the DUT is appropriately configured to provide the appropriate test environment. As with any properly orchestrated test effort, the test plan document should reflect these and other relevant details and should be written with close attention to the expected production operating environment. The combined analysis of the results of each phase will characterize the overall ISSU process with the main goal of being able to identify and quantify any disruption in service (from the data- and control-plane perspective) allowing operators to plan their maintenance activities with greater precision.
ISSUプロセスは、以下に定義するように、一連の異なるフェーズまたはアクティビティと見なすことができます。これらのフェーズごとに、テストオペレーターは結果と関連する観察結果（本ドキュメントでさらに定義）を記録する必要があります。特定のベンダーの実装では、特定の段階で進行中のISSUを中止できる場合とできない場合があることに注意してください。特定の機能構成が与えられたISSUの可用性に関して特定の制限がある場合もあります（たとえば、双方向障害検出（BFD）[RFC5880]が存在する場合のISSUはサポートされない場合があります）。 DUTが適切なテスト環境を提供するように適切に構成されていることを確認するのは、テストオペレーターの責任です。適切に調整されたテスト作業と同様に、テスト計画文書はこれらおよびその他の関連する詳細を反映し、予想される運用環境に細心の注意を払って作成する必要があります。各フェーズの結果を組み合わせて分析することで、ISSUプロセス全体を特徴づけ、サービスの中断を（データプレーンとコントロールプレーンの観点から）識別して定量化し、オペレーターがより大きなメンテナンスアクティビティを計画できるようにすることを主な目標とします。精度。
In this first phase, the requested software package may be downloaded to the router and is typically stored onto a device. The downloading of software may be performed automatically by the device as part of the upgrade process, or it may be initiated separately. Such separation allows an administrator to download the new code inside or outside of a maintenance window; it is anticipated that downloading new code and saving it to disk on the router will not impact operations. In the case where the software can be downloaded outside of the actual upgrade process, the administrator should do so; downloading software can skew timing results based on factors that are often not comparative in nature. Internal compatibility verification may be performed by the software running on the DUT, to verify the checksum of the files downloaded as well as any other pertinent checks. Depending upon vendor implementation, these mechanisms may include 1) verifying that the downloaded module(s) meet a set of identified prerequisites such as (but not limited to) hardware or firmware compatibility or minimum software requirements or even 2) ensuring that device is "authorized" to run the target software.
この最初のフェーズでは、要求されたソフトウェアパッケージをルーターにダウンロードし、通常はデバイスに保存します。ソフトウェアのダウンロードは、アップグレードプロセスの一部としてデバイスによって自動的に実行される場合と、個別に開始される場合があります。このような分離により、管理者はメンテナンスウィンドウの内外で新しいコードをダウンロードできます。新しいコードをダウンロードしてルーターのディスクに保存しても、運用に影響はないことが予想されます。実際のアップグレードプロセス以外でソフトウェアをダウンロードできる場合は、管理者がダウンロードする必要があります。ソフトウェアをダウンロードすると、本質的に比較されないことが多い要因に基づいてタイミング結果が歪む可能性があります。 DUTで実行されているソフトウェアによって内部互換性検証が実行され、ダウンロードされたファイルのチェックサムおよびその他の関連するチェックが検証されます。ベンダーの実装に応じて、これらのメカニズムには、1）ダウンロードしたモジュールが、ハードウェアまたはファームウェアの互換性または最小ソフトウェア要件などの（ただしこれらに限定されない）識別された前提条件のセットを満たしていることの確認、または2）デバイスが「ターゲットソフトウェアを実行することを許可されています。
Where such mechanisms are made available by the product, they should be verified, by the tester, with the goal of avoiding operational issues in production. Verification should include both positive verification (ensuring that an ISSU action should be permitted) as well as negative tests (creation of scenarios where the verification mechanisms would report exceptions).
このようなメカニズムが製品で利用できるようになっている場合、本番環境での運用上の問題を回避することを目的として、テスターがそれらを検証する必要があります。検証には、肯定的な検証（ISSUアクションを確実に許可する）と否定的なテスト（検証メカニズムが例外を報告するシナリオの作成）の両方を含める必要があります。
In this second phase, the requested software package is loaded in the pertinent components of a given forwarding device (typically the RP in standby state). Internal compatibility verification may be performed by the software running on the DUT, as part of the upgrade process itself, to verify the checksum of the files downloaded as well as any other pertinent checks. Depending upon vendor implementation, these mechanisms may include verification that the downloaded module(s) meet a set of identified prerequisites such as hardware or firmware compatibility or minimum software requirements. Where such mechanisms are made available by the product, they should be verified, by the tester (again with the goal of avoiding operational issues in production). In this case, the execution of these checks is within the scope of the upgrade time and should be included in the testing results. Once the new software is downloaded to the pertinent components of the DUT, the upgrade begins, and the DUT begins to prepare itself for upgrade. Depending on the vendor implementation, it is expected that redundant hardware pieces within the DUT are upgraded, including the backup or secondary RP.
この2番目のフェーズでは、要求されたソフトウェアパッケージが所定の転送デバイス（通常はスタンバイ状態のRP）の関連コンポーネントにロードされます。アップグレードプロセス自体の一部として、DUTで実行されているソフトウェアによって内部互換性検証が実行され、ダウンロードされたファイルのチェックサムおよびその他の関連するチェックが検証されます。ベンダーの実装に応じて、これらのメカニズムには、ダウンロードされたモジュールが、ハードウェアまたはファームウェアの互換性や最小ソフトウェア要件など、特定された一連の前提条件を満たしているかどうかの検証が含まれます。そのようなメカニズムが製品で利用できるようになっている場合は、テスター（これも本番環境での運用上の問題を回避することを目的とする）によって検証される必要があります。この場合、これらのチェックの実行はアップグレード時間の範囲内であり、テスト結果に含める必要があります。新しいソフトウェアがDUTの関連コンポーネントにダウンロードされると、アップグレードが始まり、DUTがアップグレードの準備を始めます。ベンダーの実装によっては、バックアップまたはセカンダリRPを含め、DUT内の冗長ハードウェア部分がアップグレードされることが予想されます。
In this phase, a switchover of RPs may take place, where one RP is now upgraded with the new version of software. More importantly, the "Upgrade Run" phase is where the internal changes made to information and state (stored on the router, on disk, and in memory) are either migrated to the "new" version of code, or transformed/rebuilt to meet the standards of the new version of code, and pushed onto the appropriate pieces of hardware. It is within this phase that any outage(s) on the control or forwarding plane may be expected to be observed. This is the critical phase of the ISSU, where the control plane should not be impacted and any interruptions to the forwarding plane should be minimal to none.
このフェーズでは、RPのスイッチオーバーが行われる場合があり、1つのRPが新しいバージョンのソフトウェアでアップグレードされます。さらに重要なのは、「アップグレードの実行」フェーズでは、情報と状態に加えられた内部変更（ルーター、ディスク、メモリに保存されている）が「新しい」バージョンのコードに移行されるか、満たすために変換/再構築される新しいバージョンのコードの標準であり、適切なハードウェアにプッシュされます。コントロールまたはフォワーディングプレーンの停止が観察されることが予想されるのは、このフェーズ内です。これはISSUの重要なフェーズであり、コントロールプレーンに影響を与えてはならず、フォワーディングプレーンへの中断は最小限に抑える必要があります。
If any control- or data-plane interruptions are observed within this stage, they should be recorded as part of the results document.
この段階でコントロールプレーンまたはデータプレーンの中断が確認された場合は、結果ドキュメントの一部として記録する必要があります。
For some implementations, the two stages, as described in Section 3.2 and above, may be concatenated into one monolithic operation. In that case, the calculation of the respective ISSU time intervals may need to be adapted accordingly.
一部の実装では、セクション3.2以上で説明した2つのステージを1つのモノリシック操作に連結できます。その場合、それぞれのISSU時間間隔の計算をそれに応じて調整する必要があります。
In this phase, the new version of software must be running in all the physical nodes of the logical forwarding device (RPs and line cards as applicable). At this point, configuration control is returned to the operator, and normal device operation, i.e., outside of ISSU-oriented operation, is resumed.
このフェーズでは、新しいバージョンのソフトウェアが論理転送デバイスのすべての物理ノード（RPおよび該当する場合はラインカード）で実行されている必要があります。この時点で、構成制御はオペレーターに戻され、通常のデバイス操作、つまりISSU指向の操作以外の操作が再開されます。
As stated by [RFC6815], the Test Topology Setup must be part of an Isolated Test Environment (ITE).
[RFC6815]で述べられているように、テストトポロジセットアップは分離テスト環境（ITE）の一部である必要があります。
The reporting of results must take into account the repeatability considerations from Section 4 of [RFC2544]. It is RECOMMENDED to perform multiple trials and report average results. The results are reported in a simple statement including the measured frame loss and ISSU impact times.
結果の報告では、[RFC2544]のセクション4の再現性に関する考慮事項を考慮する必要があります。複数の試験を実施して平均結果を報告することをお勧めします。結果は、測定されたフレーム損失とISSU影響時間を含む簡単なステートメントで報告されます。
The hardware configuration of the DUT (Device Under Test) should be identical to the one expected to be or currently deployed in production in order for the benchmark to have relevance. This would include the number of RPs, hardware version, memory, and initial software release, any common chassis components, such as fabric hardware in the case of a fabric-switching platform, and the specific line cards (version, memory, interfaces type, rate, etc.).
DUT（Device Under Test）のハードウェア構成は、ベンチマークに関連性を持たせるために、本番環境で展開される予定の、または現在展開されているものと同じでなければなりません。これには、RPの数、ハードウェアバージョン、メモリ、初期ソフトウェアリリース、ファブリックスイッチングプラットフォームの場合のファブリックハードウェアなどの一般的なシャーシコンポーネント、および特定のラインカード（バージョン、メモリ、インターフェイスタイプ、レートなど）。
For the control and data plane, differing configuration approaches may be utilized. The recommended approach relies on "mimicking" the existing production data- and control-plane information, in order to emulate all the necessary Layer 1 through Layer 3 communications and, if appropriate, the upper-layer characteristics of the network, as well as end-to-end traffic/communication pairs. In other words, design a representative load model of the production environment and deploy a collapsed topology utilizing test tools and/or external devices, where the DUT will be tested. Note that, the negative impact of ISSU operations is likely to impact scaled, dynamic topologies to a greater extent than simpler, static environments. As such, this methodology (based upon production configuration) is advised for most test scenarios.
コントロールプレーンとデータプレーンでは、異なる構成アプローチを使用できます。推奨されるアプローチは、必要なすべてのレイヤー1からレイヤー3の通信をエミュレートし、必要に応じてネットワークの上位レイヤーの特性とエンドをエミュレートするために、既存のプロダクションデータとコントロールプレーンの情報を「模倣」することです。 -to-endトラフィック/通信ペア。つまり、本番環境の代表的な負荷モデルを設計し、DUTがテストされるテストツールや外部デバイスを使用して、折りたたまれたトポロジを展開します。 ISSU運用の悪影響は、単純な静的環境よりも、スケーリングされた動的トポロジに大きな影響を与える可能性があることに注意してください。そのため、この方法（本番構成に基づく）は、ほとんどのテストシナリオで推奨されます。
The second, more simplistic approach is to deploy an ITE in which endpoints are "directly" connected to the DUT. In this manner, control-plane information is kept to a minimum (only connected interfaces), and only a basic data-plane of sources and destinations is applied. If this methodology is selected, care must be taken to understand that the systemic behavior of the ITE may not be identical to that experienced by a device in a production network role. That is, control-plane validation may be minimal to none with this methodology. Consequently, if this approach is chosen, comparison with at least one production configuration is recommended in order to understand the direct relevance and limitations of the test exercise.
2番目のより単純なアプローチは、エンドポイントがDUTに「直接」接続されているITEを展開することです。このようにして、コントロールプレーン情報は最小限に抑えられ（接続されたインターフェイスのみ）、送信元と宛先の基本的なデータプレーンのみが適用されます。この方法論を選択する場合、ITEの体系的な動作が、実稼働ネットワークの役割のデバイスが経験する動作と同じでない可能性があることを理解するように注意する必要があります。つまり、この方法では、コントロールプレーンの検証を最小限に抑えることができます。したがって、このアプローチを選択する場合は、テストの直接的な関連性と制限を理解するために、少なくとも1つの実稼働構成と比較することをお勧めします。
In consideration of the defined test topology, a load model must be developed to exercise the DUT while the ISSU event is introduced. This applied load should be defined in such a manner as to provide a granular, repeatable verification of the ISSU impact on transit traffic. Sufficient traffic load (rate) should be applied to permit timing extrapolations at a minimum granularity of 100 milliseconds, e.g., 100 Mbps for a 10 Gbps interface. The use of steady traffic streams rather than bursty loads is preferred to simplify analysis.
定義されたテストトポロジを考慮して、ISSUイベントの導入中にDUTを実行するための負荷モデルを開発する必要があります。この適用される負荷は、通過トラフィックへのISSUの影響をきめ細かく再現性のある方法で検証できるように定義する必要があります。十分なトラフィック負荷（レート）を適用して、100ミリ秒の最小粒度（10 Gbpsインターフェースの場合は100 Mbpsなど）でタイミングを外挿できるようにする必要があります。分析を簡素化するには、バースト性のある負荷ではなく、安定したトラフィックストリームを使用することをお勧めします。
The traffic should be patterned to provide a broad range of source and destination pairs, which resolve to a variety of FIB (Forwarding Information Base) prefix lengths. If the production network environment includes multicast traffic or VPNs (L2, L3, or IPsec), it is critical to include these in the model.
トラフィックをパターン化して、さまざまな送信元と宛先のペアを提供し、さまざまなFIB（転送情報ベース）プレフィックス長に解決する必要があります。実稼働ネットワーク環境にマルチキャストトラフィックまたはVPN（L2、L3、またはIPsec）が含まれている場合、これらをモデルに含めることが重要です。
For mixed protocol environments (e.g., IPv4 and IPv6), frames should be distributed between the different protocols. The distribution should approximate the network conditions of deployment. In all cases, the details of the mixed protocol distribution must be included in the reporting.
混合プロトコル環境（IPv4とIPv6など）の場合、フレームは異なるプロトコル間で分散する必要があります。ディストリビューションは、展開のネットワーク条件に近似する必要があります。すべての場合において、混合プロトコル配布の詳細をレポートに含める必要があります。
The feature, protocol timing, and other relevant configurations should be matched to the expected production environment. Deviations from the production templates may be deemed necessary by the test operator (for example, certain features may not support ISSU or the test bed may not be able to accommodate such). However, the impact of any such divergence should be clearly understood, and the differences must be recorded in the results documentation. It is recommended that a Network Management System (NMS) be deployed, preferably similar to that utilized in production. This will allow for monitoring of the DUT while it is being tested, both in terms of supporting the impact analysis on system resources as well as detecting interference with non-transit (management) traffic as a result of the ISSU operation. It is suggested that the actual test exercise be managed utilizing direct console access to the DUT, if at all possible, to avoid the possibility that a network interruption impairs execution of the test exercise.
機能、プロトコルタイミング、およびその他の関連構成は、予想される実稼働環境に一致させる必要があります。運用テンプレートからの逸脱は、テストオペレーターによって必要と見なされる場合があります（たとえば、特定の機能がISSUをサポートしていない場合や、テストベッドがそのように対応できない場合があります）。ただし、そのような相違の影響は明確に理解する必要があり、その違いは結果の文書に記録する必要があります。ネットワーク管理システム（NMS）を展開することをお勧めします。できれば、本番環境で使用されるものと同様です。これにより、システムリソースへの影響分析のサポートと、ISSU操作の結果としての非転送（管理）トラフィックへの干渉の検出の両方に関して、テスト中にDUTを監視できます。ネットワークの中断がテスト演習の実行を妨げる可能性を回避するために、可能であれば、DUTへの直接コンソールアクセスを利用して実際のテスト演習を管理することをお勧めします。
All in all, the load model should attempt to simulate the production network environment to the greatest extent possible in order to maximize the applicability of the results generated.
全体として、負荷モデルは、生成される結果の適用性を最大化するために、可能な限り本番ネットワーク環境をシミュレートするように試みるべきです。
As previously described, for the purposes of this test document, the ISSU process is divided into three main phases. The following methodology assumes that a suitable test topology has been constructed per Section 4. A description of the methodology to be applied for each of the above phases follows.
前述のように、このテストドキュメントの目的のために、ISSUプロセスは3つの主要なフェーズに分かれています。次の方法論は、セクション4に従って適切なテストトポロジが構築されていることを前提としています。上記の各フェーズに適用される方法論の説明を以下に示します。
The steps of this phase are as follows.
このフェーズの手順は次のとおりです。
1. Verify that enough hardware and software resources are available to complete the Load operation (e.g., enough disk space).
1. ロード操作を完了するのに十分なハードウェアおよびソフトウェアリソースが利用可能であることを確認します（たとえば、十分なディスク領域）。
2. Verify that the redundancy states between RPs and other nodes are as expected (e.g., redundancy on, RPs synchronized).
2. RPと他のノード間の冗長性の状態が期待どおりであることを確認します（冗長性がオン、RPが同期されているなど）。
3. Verify that the device, if running protocols capable of NSR (Non-Stop Routing), is in a "ready" state; that is, that the sync between RPs is complete and the system is ready for failover, if necessary.
3. NSR（ノンストップルーティング）対応のプロトコルを実行している場合、デバイスが「準備完了」状態であることを確認します。つまり、RP間の同期が完了し、システムは必要に応じてフェイルオーバーの準備ができています。
4. Gather a configuration snapshot of the device and all of its applicable components.
4. デバイスとそのすべての適用可能なコンポーネントの構成スナップショットを収集します。
5. Verify that the node is operating in a "steady" state (that is, no critical or maintenance function is being currently performed).
5. ノードが「定常」状態で動作している（つまり、現在重要な機能やメンテナンス機能が実行されていない）ことを確認します。
6. Note any other operational characteristics that the tester may deem applicable to the specific implementation deployed.
6. テスターが展開された特定の実装に適用可能であると見なす可能性があるその他の運用上の特徴に注意してください。
The steps of this phase are as follows.
このフェーズの手順は次のとおりです。
1. Establish all relevant protocol adjacencies and stabilize routing within the test topology. In particular, ensure that the scaled levels of the dynamic protocols are dimensioned as specified by the test topology plan.
1. 関連するすべてのプロトコル隣接関係を確立し、テストトポロジ内のルーティングを安定させます。特に、動的プロトコルのスケーリングされたレベルが、テストトポロジプランで指定されているとおりにディメンション化されていることを確認してください。
2. Clear, relevant logs and interface counters to simplify analysis. If possible, set logging timestamps to a highly granular mode. If the topology includes management systems, ensure that the appropriate polling levels have been applied, sessions have been established, and the responses are per expectation.
2. 分析を簡素化するために、明確で関連のあるログとインターフェースカウンター。可能であれば、ロギングタイムスタンプを非常に細かいモードに設定します。トポロジに管理システムが含まれている場合は、適切なポーリングレベルが適用されていること、セッションが確立されていること、および応答が期待どおりであることを確認してください。
3. Apply the traffic loads as specified in the load model previously developed for this exercise.
3. この演習用に以前に開発した負荷モデルで指定されているトラフィック負荷を適用します。
4. Document an operational baseline for the test bed with relevant data supporting the above steps (include all relevant load characteristics of interest in the topology, e.g., routing load, traffic volumes, memory and CPU utilization).
4. 上記の手順をサポートする関連データを使用して、テストベッドの運用ベースラインを文書化します（ルーティング負荷、トラフィック量、メモリ、CPU使用率など、トポロジに関連するすべての関連負荷特性を含めます）。
5. Note the start time (T0) and begin the code change process utilizing the appropriate mechanisms as expected to be used in production (e.g., active download with TFTP, FTP, SCP, etc., or direct install from local or external storage facility). In order to ensure that ISSU process timings are not skewed by the lack of a network-wide synchronization source, the use of a network NTP source is encouraged.
5. 開始時刻（T0）をメモし、本番環境での使用が想定される適切なメカニズム（TFTP、FTP、SCPなどによるアクティブダウンロード、またはローカルまたは外部のストレージファシリティからの直接インストールなど）を使用してコード変更プロセスを開始します。 ISSUプロセスのタイミングがネットワーク全体の同期ソースの欠如によって歪められないようにするために、ネットワークNTPソースの使用をお勧めします。
6. Take note of any logging information and command-line interface (CLI) prompts as needed. (This detail will be vendor specific.) Respond to any DUT prompts in a timely manner.
6. 必要に応じて、ログ情報とコマンドラインインターフェイス（CLI）プロンプトをメモします。 （この詳細はベンダー固有です。）DUTプロンプトにタイムリーに応答します。
7. Monitor the DUT for the reload of the secondary RP to the new software level. Once the secondary has stabilized on the new code, note the completion time. The duration of these steps will be recorded as "T1".
7. DUTを監視して、セカンダリRPが新しいソフトウェアレベルにリロードされるかどうかを確認します。セカンダリが新しいコードで安定したら、完了時間に注意してください。これらのステップの継続時間は「T1」として記録されます。
8. Review system logs for any anomalies, check that relevant dynamic protocols have remained stable, and note traffic loss if any. Verify that deployed management systems have not identified any unexpected behavior.
8. 異常がないかシステムログを確認し、関連する動的プロトコルが安定していることを確認し、トラフィック損失がある場合はそれを記録します。展開された管理システムが予期しない動作を識別していないことを確認します。
The following assumes that the software load step and upgrade step are discretely controllable. If not, maintain the aforementioned timer and monitor for completion of the ISSU as described below.
以下は、ソフトウェアのロード手順とアップグレード手順が個別に制御可能であることを前提としています。そうでない場合は、前述のタイマーを維持し、ISSUの完了を以下のように監視します。
1. Note the start time and initiate the actual upgrade procedure.
1. 開始時刻をメモし、実際のアップグレード手順を開始します。
2. Monitor the operation of the secondary route processor while it initializes with the new software and assumes mastership of the DUT. At this point, pay particular attention to any indications of control-plane disruption, traffic impact, or other anomalous behavior. Once the DUT has converged upon the new code and returned to normal operation, note the completion time and log the duration of this step as "T2".
2.新しいソフトウェアで初期化し、DUTのマスターシップを引き受ける間に、セカンダリルートプロセッサの動作を監視します。この時点で、コントロールプレーンの中断、トラフィックへの影響、またはその他の異常な動作の兆候に特に注意してください。 DUTが新しいコードに収束して通常の動作に戻ったら、完了時間を記録し、このステップの継続時間を「T2」として記録します。
3. Review the syslog data in the DUT and neighboring devices for any behavior that would be disruptive in a production environment (line card reloads, control-plane flaps, etc.). Examine the traffic generators for any indication of traffic loss over this interval. If the Test Set reported any traffic loss, note the number of frames lost as "TPL_frames", where TPL stands for "Total Packet Loss". If the Test Set also provides outage duration, note this as "TPL_time". (Alternatively, TPL_time may be calculated as (TPL / Offered Load) * 1000. The units for Offered Load are packets per second; the units for TPL_time are milliseconds.)
3. DUTと隣接デバイスのsyslogデータを調べて、実稼働環境で混乱を招くような動作（ラインカードのリロード、コントロールプレーンフラップなど）がないか確認します。この間隔でのトラフィック損失の兆候がないか、トラフィックジェネレータを調べます。テストセットがトラフィックの損失を報告した場合は、失われたフレームの数を「TPL_frames」としてメモします。TPLは「合計パケット損失」を表します。テストセットが停止期間も提供する場合は、これを「TPL_time」としてメモします。 （または、TPL_timeは（TPL /提供負荷）* 1000として計算できます。提供負荷の単位は1秒あたりのパケット数、TPL_timeの単位はミリ秒です。）
4. Verify the DUT status observations as per any NMS managing the DUT and its neighboring devices. Document the observed CPU and memory statistics both during and after the ISSU upgrade event, and ensure that memory and CPU have returned to an expected (previously baselined) level.
4. DUTとその隣接デバイスを管理するNMSごとに、DUTステータスの観測を確認します。 ISSUアップグレードイベント中とその後の両方で観察されたCPUとメモリの統計を文書化し、メモリとCPUが予期した（以前のベースライン）レベルに戻ったことを確認します。
The following describes a set of post-ISSU verification tasks that are not directly part of the ISSU process, but are recommended for execution in order to validate a successful upgrade.
次に、ISSUプロセスの一部ではないが、正常なアップグレードを検証するために実行することが推奨される、ISSU後の検証タスクのセットについて説明します。
1. Configuration delta analysis
1. 構成デルタ分析
Examine the post-ISSU configurations to determine if any changes have occurred either through process error or due to differences in the implementation of the upgraded code.
ISSU後の構成を調べて、プロセスエラーによって、またはアップグレードされたコードの実装の違いが原因で変更が発生したかどうかを判断します。
2. Exhaustive control-plane analysis
2. 徹底的なコントロールプレーン分析
Review the details of the Routing Information Base (RIB) and FIB to assess whether any unexpected changes have been introduced in the forwarding paths.
ルーティング情報ベース（RIB）とFIBの詳細を確認して、転送パスに予期しない変更が加えられていないかどうかを評価します。
3. Verify that both RPs are up and that the redundancy mechanism for the control plane is enabled and fully synchronized.
3. 両方のRPが起動していること、およびコントロールプレーンの冗長メカニズムが有効で完全に同期されていることを確認します。
4. Verify that no control-plane (protocol) events or flaps were detected.
4. コントロールプレーン（プロトコル）イベントまたはフラップが検出されなかったことを確認します。
5. Verify that no L1 and or L2 interface flaps were observed.
5. L1またはL2インターフェイスフラップが観察されなかったことを確認します。
6. Document the hitless operation or presence of an outage based upon the counter values provided by the Test Set.
6. テストセットによって提供されるカウンター値に基づいて、ヒットレス操作または停止の存在を文書化します。
As an OPTIONAL Test Case, the operator may want to perform an ISSU test while the DUT is under stress by introducing route churn to any or all of the involved phases of the ISSU process.
オプションのテストケースとして、オペレーターは、ISSUプロセスの関連するフェーズのいずれかまたはすべてにルートチャーンを導入することにより、DUTにストレスがかかっている間にISSUテストを実行することができます。
One approach relies on the operator to gather statistical information from the production environment and determine a specific number of routes to flap every 'fixed' or 'variable' interval. Alternatively, the operator may wish to simply preselect a fixed number of prefixes to flap. As an example, an operator may decide to flap 1% of all the BGP routes every minute and restore them 1 minute afterwards. The tester may wish to apply this negative stimulus throughout the entire ISSU process or, most importantly, during the run phase. It is important to ensure that these routes, which are introduced solely for stress proposes, must not overlap the ones (per the load model) specifically leveraged to calculate the TPL_time (recorded outage). Furthermore, there should not be 'operator-induced' control-plane protocol adjacency flaps for the duration of the test process as it may adversely affect the characterization of the entire test exercise. For example, triggering IGP adjacency events may force recomputation of underlying routing tables with attendant impact to the perceived ISSU timings. While not recommended, if such trigger events are desired by the test operator, care should be taken to avoid the introduction of unexpected anomalies within the test harness.
1つのアプローチは、運用環境から統計情報を収集し、「固定」または「可変」間隔ごとにフラップする特定の数のルートを決定するためにオペレーターに依存しています。代わりに、オペレーターはフラップする固定数のプレフィックスを単に事前選択することを望むかもしれません。例として、オペレーターはすべてのBGPルートの1％を毎分フラップし、1分後にそれらを復元することを決定する場合があります。テスターは、ISSUプロセス全体にわたって、または最も重要なのは実行フェーズ中に、このネガティブな刺激を適用したい場合があります。ストレス提案のためにのみ導入されたこれらのルートが、TPL_time（記録された停止）を計算するために特別に活用された（負荷モデルごとの）ルートと重複しないようにすることが重要です。さらに、テストプロセス全体の特性に悪影響を与える可能性があるため、テストプロセスの期間中は、「オペレーターが誘発する」コントロールプレーンプロトコルの隣接フラップが存在しないようにしてください。たとえば、IGP隣接イベントをトリガーすると、基礎となるルーティングテーブルの再計算が強制され、認識されたISSUタイミングに付随する影響が生じる可能性があります。推奨されませんが、そのようなトリガーイベントがテストオペレーターによって望まれる場合、テストハーネス内で予期しない異常が発生しないように注意する必要があります。
Where a vendor provides such support, the ISSU process could be aborted for any reason by the operator. However, the end results and behavior may depend on the specific phase where the process was aborted. While this is implementation dependent, as a general recommendation, if the process is aborted during the "Software Download" or "Software Staging" phases, no impact to service or device functionality should be observed. In contrast, if the process is aborted during the "Upgrade Run" or "Upgrade Accept" phases, the system may reload and revert back to the previous software release, and, as such, this operation may be service affecting. Where vendor support is available, the abort/rollback functionality should be verified, and the impact, if any, quantified generally following the procedures provided above.
ベンダーがそのようなサポートを提供している場合、ISSUプロセスはオペレーターによって何らかの理由で中止される可能性があります。ただし、最終結果と動作は、プロセスが中止された特定のフェーズによって異なる場合があります。これは実装に依存しますが、一般的な推奨事項として、「ソフトウェアのダウンロード」または「ソフトウェアのステージング」フェーズ中にプロセスが中止された場合、サービスやデバイスの機能への影響は観察されません。対照的に、「アップグレードの実行」または「アップグレードの承認」フェーズ中にプロセスが中止された場合、システムがリロードして以前のソフトウェアリリースに戻る可能性があるため、この操作がサービスに影響している可能性があります。ベンダーのサポートが利用可能な場合は、中止/ロールバック機能を検証し、一般に上記の手順に従って影響を定量化する必要があります。
All ISSU impact results are summarized in a simple statement describing the "ISSU Disruption Impact" including the measured frame loss and impact time, where impact time is defined as the time frame determined per the TPL_time reported outage. These are considered to be the primary data points of interest.
すべてのISSU影響の結果は、測定されたフレーム損失と影響時間を含む「ISSU Disruption Impact」を説明する簡単なステートメントに要約されます。影響時間は、TPL_time報告された停止ごとに決定された時間フレームとして定義されます。これらは、主要なデータポイントと見なされます。
However, the entire ISSU operational impact should also be considered in support of planning for maintenance, and, as such, additional reporting points are included.
ただし、ISSUの運用上の影響全体も、メンテナンスの計画をサポートするために考慮する必要があります。そのため、追加のレポートポイントが含まれています。
Software download / secondary update T1
ソフトウェアのダウンロード/二次更新T1
Upgrade/Run T2
T2のアップグレード/実行
ISSU Traffic Disruption (Frame Loss) TPL_frames
ISSUトラフィックの中断（フレーム損失）TPL_frames
ISSU Traffic Impact Time (milliseconds) TPL_time
ISSUトラフィック影響時間（ミリ秒）TPL_time
ISSU Housekeeping Interval T3
ISSUハウスキーピング間隔T3
(Time for both RPs up on new code and fully synced - Redundancy restored)
（両方のRPが新しいコードで稼働し、完全に同期されるまでの時間-冗長性が復元されました）
Total ISSU Maintenance Window T4 (sum of T1+T2+T3)
ISSUメンテナンスウィンドウT4の合計（T1 + T2 + T3の合計）
The results reporting must provide the following information:
結果報告では、次の情報を提供する必要があります。
- DUT hardware and software detail
- DUTハードウェアおよびソフトウェアの詳細
- Test Topology definition and diagram (especially as related to the ISSU operation)
- テストトポロジの定義と図（特にISSU操作に関連するもの）
- Load Model description including protocol mixes and any divergence from the production environment
- プロトコルミックスや本番環境からの逸脱を含むモデルの説明を読み込みます
- Time Results as per above
- 上記の時間結果
- Anomalies Observed during ISSU
- ISSU中に観察された異常
- Anomalies Observed in post-ISSU analysis It is RECOMMENDED that the following parameters be reported as outlined below:
-ISSU後の分析で観察された異常以下のパラメータは、以下に概説するように報告することをお勧めします。
Parameter Units or Examples
---------------------------------------------------------------
Traffic Load Frames per second and bits per second
トラフィックロードフレーム/秒およびビット/秒
Disruption (average) Frames
中断（平均）フレーム
Impact Time (average) Milliseconds
影響時間（平均）ミリ秒
Number of trials Integer count
試行回数整数カウント
Protocols IPv4, IPv6, MPLS, etc.
プロトコルIPv4、IPv6、MPLSなど
Frame Size Octets
フレームサイズオクテット
Port Media Ethernet, Gigabit Ethernet (GbE), Packet over SONET (POS), etc.
ポートメディアイーサネット、ギガビットイーサネット（GbE）、Packet over SONET（POS）など
Port Speed 10 Gbps, 1 Gbps, 100 Mbps, etc.
ポート速度10 Gbps、1 Gbps、100 Mbpsなど
Interface Encaps Ethernet, Ethernet VLAN, PPP, High-Level Data Link Control (HDLC), etc.
インターフェースカプセル化イーサネット、イーサネットVLAN、PPP、ハイレベルデータリンクコントロール（HDLC）など。
Number of Prefixes Integer count
プレフィックス数整数カウント
flapped (ON Interval) (Optional) # of prefixes / Time (min.)
フラップ（ON間隔）（オプション）プレフィックスの数/時間（分）
flapped (OFF Interval) (Optional) # of prefixes / Time (min.)
フラップ（OFF間隔）（オプション）プレフィックスの数/時間（分）
Document any configuration deltas that are observed after the ISSU upgrade has taken effect. Note differences that are driven by changes in the patch or release level, as well as items that are aberrant changes due to software faults. In either of these cases, any unexpected behavioral changes should be analyzed and a determination made as to the impact of the change (be it functional variances or operational impacts to existing scripts or management mechanisms).
ISSUアップグレードが有効になった後に観察された構成デルタを文書化します。パッチまたはリリースレベルの変更によって引き起こされる違い、およびソフトウェア障害による異常な変更である項目に注意してください。これらのいずれの場合でも、予期しない動作の変更を分析し、変更の影響（既存のスクリプトまたは管理メカニズムに対する機能上の差異または運用上の影響）について決定を行う必要があります。
When a DUT is undergoing an ISSU operation, it's worth noting that the DUT's data collection and reporting of data, such as counters, interface statistics, log messages, etc., may not be accurate. As such, one should not rely on the DUT's data collection methods, but rather, should use the test tools and equipment to collect data used for reporting in Section 7. Care and consideration should be paid in testing or adding new test cases, such that the desired data can be collected from the test tools themselves, or other external equipment, outside of the DUT itself.
DUTがISSU操作を実行しているとき、DUTのデータ収集と、カウンター、インターフェース統計、ログメッセージなどのデータのレポートが正確でない場合があることに注意してください。そのため、DUTのデータ収集方法に依存するのではなく、テストツールと機器を使用して、セクション7のレポートに使用されるデータを収集する必要があります。テストまたは新しいテストケースの追加には、注意と配慮が必要です。必要なデータは、DUT自体の外部のテストツール自体またはその他の外部機器から収集できます。
All BMWG memos are limited to testing in a laboratory Isolated Test Environment (ITE), thus avoiding accidental interruption to production networks due to test activities.
すべてのBMWGメモは、実験室の隔離されたテスト環境（ITE）でのテストに限定されているため、テストアクティビティによる偶発的な生産ネットワークの中断を回避できます。
All benchmarking activities are limited to technology characterization using controlled stimuli in a laboratory environment with dedicated address space and the other constraints [RFC2544].
すべてのベンチマークアクティビティは、専用のアドレススペースとその他の制約[RFC2544]を備えた実験室環境で制御された刺激を使用した技術の特性評価に限定されます。
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.
ベンチマークネットワークトポロジは独立したテストセットアップであり、テストトラフィックを実稼働ネットワークに転送したり、トラフィックをテスト管理ネットワークに誤ってルーティングする可能性のあるデバイスに接続してはなりません。
Further, benchmarking is performed on a "black-box" basis, relying solely on measurements observable external to the Device Under Test / System Under Test (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から生じるネットワークセキュリティへの影響は、ラボと実稼働ネットワークで同じである必要があります。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。
[RFC2544] Bradner, S. and J. McQuaid, "Benchmarking Methodology for Network Interconnect Devices", RFC 2544, DOI 10.17487/RFC2544, March 1999, <http://www.rfc-editor.org/info/rfc2544>.
[RFC2544] Bradner、S。およびJ. McQuaid、「ネットワーク相互接続デバイスのベンチマーク手法」、RFC 2544、DOI 10.17487 / RFC2544、1999年3月、<http://www.rfc-editor.org/info/rfc2544>。
[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, <http://www.rfc-editor.org/info/rfc5880>.
[RFC5880] Katz、D。およびD. Ward、「Bidirectional Forwarding Detection（BFD）」、RFC 5880、DOI 10.17487 / RFC5880、2010年6月、<http://www.rfc-editor.org/info/rfc5880>。
[RFC6815] Bradner, S., Dubray, K., McQuaid, J., and A. Morton, "Applicability Statement for RFC 2544: Use on Production Networks Considered Harmful", RFC 6815, DOI 10.17487/RFC6815, November 2012, <http://www.rfc-editor.org/info/rfc6815>.
[RFC6815] Bradner、S.、Dubray、K.、McQuaid、J.、and A. Morton、 "Applicability Statement for RFC 2544：Use on Production Networks考慮される有害"、RFC 6815、DOI 10.17487 / RFC6815、2012年11月、< http://www.rfc-editor.org/info/rfc6815>。
Acknowledgments
謝辞
The authors wish to thank Vibin Thomas for his valued review and feedback.
著者は、彼の貴重なレビューとフィードバックのためにVibin Thomasに感謝したいと思います。
Authors' Addresses
著者のアドレス
Sarah Banks VSS Monitoring Email: sbanks@encrypted.net
Sarah Banks VSS監視メール：sbanks@encrypted.net
Fernando Calabria Cisco Systems Email: fcalabri@cisco.com
フェルナンドカラブリアシスコシステムズの電子メール：fcalabri@cisco.com
Gery Czirjak Juniper Networks Email: gczirjak@juniper.net
Gery Czirjak Juniper Networksメール：gczirjak@juniper.net
Ramdas Machat Juniper Networks Email: rmachat@juniper.net
Ramdas Machat Juniper Networksメール：rmachat@juniper.net