RFC 7747: データ・プレーン・コンバージェンスのための基本的なBGPコンバージェンス・ベンチマーク手法

要旨

BGPは、デフォルトのAS (自律システム)間ルーティング・プロトコルとして、サービス・プロバイダに広く導入され、使用されている。BGPピアまたはBGPピアのダウンストリーム・リンクに障害が発生した場合、代替パスが迅速に使用され、これらの代替パスを経由する経路がインストールされるようにすることが最も重要な機能である。本文書では、RFC 4098で定義されている既存のBGPコンバージェンス用語を使用して、基本的なBGPベンチマーク方法を説明する。

本文書の位置付け

本文書はインターネット標準化過程の仕様書ではない。情報提供を目的として公開する。

この文書はInternet Engineering Task Force (IETF)の成果物である。IETFコミュニティのコンセンサスを表すものである。公開レビューを受けており、Internet Engineering Steering Group (IESG)によって公開が承認されている。インターネット標準の詳細については、RFC 5741のセクション 2を参照のこと。

本文書の現在のステータス、正誤表、および文書に対するフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc7747 で入手できる。

著作権表示

Copyright (c) 2016 IETFトラストおよび文書の著者として特定された人物。無断転載を禁じる。

本文書は、BCP 78および文書の発行日において有効なIETF文書に関するIETFトラストの法的規定(https://trustee.ietf.org/license-info)に従うものとする。これらの文書には、本文書に関するあなたの権利と制限が記載されているため、注意深く確認して欲しい。文書から抽出されたコード・コンポーネントには、トラスト法的条項のセクション4.eに記載されている簡易BSDライセンスのテキストを含まなければならず、簡易BSDライセンスに記載されているように保証なしで提供する。

本文書には、2008年11月10日以前に公開または利用可能になったIETF文書または IETF寄稿の資料が含まれている可能性がある。このような資料の著作権を管理している人物は、 IETF標準化過程の外で変更する許可をIETFトラストに付与していない可能性がある。このような資料の著作権を管理する人物から適切なライセンスを取得しない限り、本文書をIETF標準プロセスの外で変更することはできない。また、 RFCとして公開するためにフォーマットしたり、英語以外の言語に翻訳する場合を除き、本文書の派生著作物をIETF標準化過程の外で作成することはできない。

1. はじめに

本文書は、3ノードまたは4ノードのトポロジを使用して、ルータとスイッチにおける BGPのデータ・プレーンのフォワーディング情報ベース(FIB)のコンバージェンス性能をベンチマークする方法を定義する。本文書で提案する方法は、IPv4とIPv6の両方に適用され、特定のテストが1つのバージョンに固有である場合は、それに応じてマーク付けする。IPv6ベンチマークの場合、テスト対象デバイス(DUT)はマルチプロトコルBGP(MP-BGP)[RFC4760] [RFC2545]のサポートを必要とする。同様に、内部BGP(iBGP)と外部BGP(eBGP)の両方が、該当するテストでカバーされる。

本文書の範囲は、[RFC4271]とMP-BGP[RFC4760] [RFC2545]で定義されているIPv4とIPv6に限定されたBGP機能で、BGP FIBコンバージェンスの測定の方法論を提供することである。レイヤ2及びレイヤ3の仮想プライベート・ネットワーク(VPN)をサポートするための他のBGP拡張機能は、本文書の範囲外である。IGPとのやり取り(IGPインターワーキング)は、本文書の範囲外である。

1.1. ベンチマークの定義

本文書で使用する用語は[RFC4098]で定義されている。本文書では、追加の用語を以下のように定義する。

FIB(データ・プレーン)のコンバージェンスとは、すべてのFIBの変更が完了し、すべての転送トラフィックが新しく提案された経路を通過すること、として定義される。RFC 4098では、「BGPデバイス」、「FIB」、「転送トラフィック」という用語を定義している。データ・プレーンのコンバージェンスは、ノード内のコントロール・プレーンのコンバージェンスとは異なる。

本文書は以下のテスト方法を定義する。

• データ・プレーンのコンバージェンスは、上記の範囲でBGP機能をサポートする1つのBGPデバイスで行う。そして、

• 本文書のさまざまなテストで使用されるコンバージェンス・イベントを再現するのに十分な3つまたは4つのノードのテスト・トポロジーを使用する。

1.2. BGP FIB(データ・プレーン)のコンバージェンスの目的

現在のインターネット・アーキテクチャでは、AS間トランジットは主にBGPを通じて利用できる。ドメイン内またはドメイン間の信頼性の高い接続性を維持するには、障害からの迅速な復旧が依然として最も重要である。トラフィックの損失を最小限に抑えるため、多くのサービス・プロバイダは、インターネット・ルーティング・テーブル全体をFIBレベルで1秒以内に収束させるBGP実装を要求している。

さらに、さまざまなデバイス間でこれらの数値を比較するため、サービス・プロバイダはコンバージェンス測定方法を標準化する方法も検討している。本文書では、単純なトポロジーのテスト方法を提供する。これらの簡単なテストは、さまざまなベンダーの複数の実装にわたる、BGPデータ・プレーンのコンバージェンスをハイレベルで素早くチェックすることができる。

1.3. コントロール・プレーンのコンバージェンス

BGPのコンバージェンスは、ルーティング情報ベース(RIB)とFIBのコンバージェンスという2つのレベルで発生する。RFC 4098は、BGPコントロール・プレーンのコンバージェンスに関する用語を定義している。コントロール・プレーンのコンバージェンスをテストする方法論は、本文書の範囲外である。

1.4. ベンチマーク・テスト

テストで得られた結果の再現性を保証するには、初期条件と正確な手順を慎重に設定する必要がある。

本文書では、これらの初期条件、テスト手順、結果のチェックを提案する。結果の均一性を保証するには、オプションのパラメータをすべて無効にし(SHOULD)、すべての設定をデフォルトに変更する必要がある(SHOULD)。これらにはBGPタイマーも含まれる場合がある。

2. 既存の定義と要件

「ネットワーク相互接続デバイスのベンチマーク用語」[RFC1242]と「LANスイッチング・デバイスのベンチマーク用語」[RFC2285]は、本文書と併せて検討する必要がある(SHOULD)。WLAN固有の用語と定義は、IEEE 802.11標準[IEEE.802.11]の条項3と4にも規定されている。一般的に使用される用語は、RFC 1983[RFC1983]にも記載されている。

明確さと継続性のために、本文書は[RFC1242]のセクション2で規定されているベンチマーク用語の一般的なテンプレートを採用している。定義はアルファベット順に整理され、参照しやすいようにセクションにまとめられている。スループット、レイテンシー、定負荷、フレーム損失率、およびオーバーヘッド動作という用語は、RFC 1242[RFC1242]で定義されているとおりに解釈されると想定される。さらに、転送レート、最大転送レート、負荷、テスト対象デバイス(DUT)、およびテスト対象システム(SUT)という用語は、[RFC2285]で定義されているとおりに解釈される。

キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、「OPTIONAL」は、すべて大文字で表示される場合のみ、RFC 2119 [RFC2119]に記述されているように解釈される。

3. テスト・トポロジー

このセクションでは、BGPアップデートを受信した後のFIB(データ・プレーン)のコンバージェンスを測定するBGPベンチマーク・テストで使用するテスト・セットアップについて説明する。

これらのテスト・セットアップには、次のような構成の3台または4台のノードがある。

1. 基本的なテスト設定

2. iBGPまたはeBGPコンバージェンス用の3ノードの設定

3. eBGPマルチホップ・テスト・シナリオの設定

4. iBGPまたはeBGPコンバージェンス用の4ノードの設定

個々のテストは、これらのトポロジを参照する。

図1～4では、以下の慣例(conventions)を使用している:

• AS-X: 自律システムX

• Loopback Int: BGP対応デバイス上のループバック・インタフェース

• HLP、HLP1、HLP2: DUTと同じバージョンのBGPを実行するヘルパー・ルータ

• すべてのデバイスは、NTPまたは他のクロック同期メカニズムを使用して同期されなければならない。

3.1. 一般的なリファレンス・トポロジー

エミュレータは、さまざまなテスト・ケースに対して1つ以上のBGPピアとして動作する。

図1: 基本的なテスト設定

図2: eBGPとiBGPコンバージェンス用の3ノードの設定

図3: eBGPマルチホップ・シナリオ用のBGPコンバージェンス

図4: eBGPとiBGPコンバージェンス用の4ノードの設定

4. テストに関する考慮事項

iBGPとeBGPのコンバージェンスを測定するテスト・ケースは異なる。iBGPとeBGPはどちらも、経路の広告、インストール、学習にさまざまなメカニズムを使用する。通常、DUT上のiBGP経路は、ネクストホップが有効なときにインストールされ、エクスポートされる。eBGPの場合、マルチホップ・テスト・ケース(テストで指定されている)を除き、経路はリモート・インタフェース・アドレスをネクストホップとしてDUTにインストールされる。

4.1. ピアの数

「ピア数」は、テストの開始時にDUTが持つBGPネイバー数またはセッション数として定義される。ピアはテストの開始前に確立する。その関係は、テスト・ケースの要件に応じて、iBGPまたはeBGPピアリングのいずれかになる。

DUTは、1つ以上のエミュレートされたルータまたはヘルパー・ノードと1つ以上のBGPピア・セッションを確立する。テスト要件に基づいて、追加のピアを追加できる。テスト中に有効になったピアの数は、マトリックス形式のレポートに詳しく文書化する必要がある。

4.2. ピアあたりの経路数

「ピアあたりの経路数」は、セッションあたり、またはエミュレータまたはヘルパー・ノードとの隣接関係を通じて、DUTが広告または学習する経路数として定義される。BGPネイバーとしてエミュレートするテスターは、BGPピアごとに少なくとも1つの経路を広告しなければならない(MUST)。

各テストの実行は、経路パッキング、経路ミックス、経路数の観点から経路ストリームを識別できなければならない。この経路ストリームはレポート・ストリームにきちんと文書化しなければならない。RFC 4098はこれらの用語を定義している。

ユーザは、ユニークまたはユニークでない経路を含むインターネット経路ミックスを使用して、ピアリング・セッションごとに現在のインターネット・ルーティング・テーブル全体を広告することを検討することが推奨される(RECOMMENDED)。複数のピアを使用する場合、(RFC 4098で定義されているように)ピア送信経路間のタイミング・シーケンスを正確に文書化することが重要である。

4.3. ポリシーの処理/再構成

DUTは、ポリシーがRFC 4098で定義されている最小ポリシーであるベースライン・テストを1回実行しなければならない(MUST)。追加実行は、テスト開始前に設定されたポリシーを使用して行うことができる。正確なポリシー設定は、テストの一部として文書化しなければならない(MUST)。

4.4. 設定されたパラメータ(タイマーなど)

測定されたBGPコンバージェンス時間に影響を与える可能性のあるパラメータとタイマーが設定されている。

ベンチマーク指標は、これらの設定パラメータの任意の固定値で測定してもよい(MAY)。

これらの設定パラメータは以下の設定にすることが推奨される(RECOMMENDED): a) それぞれのRFCで指定されているデフォルト値、b) プラットフォーム固有のデフォルト・パラメータ、 c) 運用ネットワークで想定される値。すべてのオプションのBGP設定は、特定のテストの繰り返す間、一貫性を保たなければならない(MUST)。

BGPコンバージェンス時間の測定値に影響を与える可能性がある設定パラメータの例には、以下があるが、これらに限定されない:

1. インタフェース障害検出タイマー
2. BGPキープアライブ・タイマー
3. BGPホールドタイム
4. BGPアップデート遅延タイマー
5. ConnectRetryタイマー
6. TCPセグメント・サイズ
7. Minimum Route Advertisement Interval (MRAI)
8. MinASOriginationInterval (MAOI)
9. 経路フラップ・ダンピング・パラメータ
10. TCP認証オプション (TCP AOまたはTCP MD5)
11. 最大TCPウィンドウ・サイズ
12. MTU

パラメータの基本テストの設定は以下のようにする必要がある。

1. インタフェース障害検出タイマー (0ミリ秒)

2. BGPキープアライブ・タイマー (1分)

3. BGPホールドタイム (3 分)

4. BGPアップデート遅延タイマー (0秒)

5. ConnectRetryタイマー (1秒)

6. TCPセグメント・サイズ (4096バイト)

7. Minimum Route Advertisement Interval (MRAI) (0秒)

8. MinASOriginationInterval (MAOI) (0秒)

9. 経路フラップ・ダンピング・パラメータ (オフ)

10. TCP認証オプション (オフ)

4.5. インタフェース・タイプ

メディアのタイプによって、どのテストケースを実行できるかが決まる。各インタフェースのタイプは、リンク障害を検出するための独自のメカニズムを持っており、そのメカニズムが動作する速度は測定結果に影響する。すべてのインタフェースは、各テストケースのすべての繰り返しにおいて、同じメディアとスループットでなければならない(MUST)。

4.6. 測定精度

観測されたパケットロスは経路コンバージェンス時間を測定するために使用されるため、個々の経路に提供される2つの連続するパケット間の時間は、パケットロスに基づく測定の中で最も高い精度となる。パケット・ジッターがコンバージェンス時間よりもはるかに小さい場合、それは無視できる誤差の原因であるため、許容範囲内として扱われる。

コンバージェンスを測定するための他のオプションには、Time-Based Loss Method (TBLM)(時間ベースの損失法)とTimestamp-Based Method (TBM) (タイムスタンプ・ベースの方法)[RFC6414]がある。

この仕様では、入力メディア(イーサネットなど)の外部測定が定義されている。

4.7. 測定統計

ベンチマークの測定値は、タイマーの期限切れ、CPUのスケジューリングなどの統計的性質により、テストごとに異なる場合がある。テストを複数回繰り返すことを推奨する。テストデータの評価は、再現性、分散、少数の試行の統計的有意性に関して、一般に受け入れられているテストの慣行を理解した上で行わなければならない。

分散を除去するために平均化される反復テストでは、すべてのパラメータが同じままでなければならない。

4.8. 認証

BGPの認証は、TCP認証オプション[RFC5925]を使用して行われる。(一部の従来の状況では、認証は引き続きTCP MD5を使用することもある)。特に多数のBGPピアと大量のアップデート・トラフィックを持つデバイスでの認証ハッシュの処理は、デバイスのコントロール・プレーンに影響を与える可能性がある。認証が有効になっている場合、レポート形式で正しく文書化されなければならない。

また、試験は同じSecure Inter-Domain Routing (SIDR)機能[RFC7115] [BGPsec]を使用しなければならない(MUST)ことが推奨される。最良のコンバージェンス・テストは、SIDR機能を使用せず、その後、同じSIDR機能を使用してコンバージェンス・テストを繰り返す。

4.9. コンバージェンス・イベント

コンバージェンス・イベントまたはトリガーは、ネットワークで発生する異常なイベントとして定義され、ネットワークで経路フラッピングを開始し、定常状態のネットワークの再コンバージェンスを強制する。実際のネットワークでは、一連のコンバージェンス・イベントが、オペレータがテストしたいコンバージェンス・レイテンシの原因となることがある。

これらのコンバージェンス・イベントは、RFC 4098で定義されているシーケンスの観点から定義しなければならない。この基本文書は、ルータの初期設定からすべてのテストを始める。追加の文書では、ピアの初期化に基づくBGPデータ・プレーンのコンバージェンスを定義する。

コンバージェンス・イベントは、実際の障害に関連付けられる場合もあれば、関連付けられない場合もある。ソフト・リセット[RFC4098]は、RIBテーブルまたはFIBテーブルはクリアしない。ハード・リセットは、BGPピア・セッション、RIBテーブル、FIBテーブルをクリアする。

4.10. 高可用性

さまざまなベンダーから、さまざまなノンストップ・ルーティング(高可用性と呼ばれることもある)のソリューションが提供されているため、コンバージェンス測定中はルーティング・プロセッサで利用可能な冗長性を無効にすることが推奨される。冗長性を無効にできない場合、結果は比較できず、測定に与える影響のレベルは本文書の範囲である。

5. テストケース

本セクションで定義されるすべてのテストは、以下を前提としている。

a. BGPピアは確立(Established)状態である。

b. 各テストの前に、BGP状態を確立状態からアイドル(Idle)状態にクリアする必要がある。これは、BGPピアが強制的にアイドル状態に戻され、データベースがフラッシュされた状態で、すべてのテストが開始されることを保証するために推奨される。

c. さらに、トラフィックの生成とルーティングをトポロジーで検証し、広告された経路にパケットロスが観察されないことを確認する必要がある。

d. 広告された経路の到着タイムスタンプは、エミュレータとDUTの間にインライン監視装置を設置するか、外部アナライザに接続されたDUTのスパンポートを使用することで測定できる。このようなインライン・モニターまたは外部アナライザーのタイムベースは、プロトコルおよびトラフィック・エミュレータと同期させる必要がある。最新のエミュレータの中には、エミュレータ・ポートを発着するすべてのNLRIパケットをキャプチャし、タイムスタンプを付ける機能を持つものがある。エミュレータとDUT間のケーブル距離が比較的短ければ、これらのNLRIパケットのタイムスタンプは、DUTへの到着時刻とほぼ一致する。

5.1. 基本コンバージェンス・テスト

これらのテストケースは、以下のような障害のないシナリオにおけるBGP実装の特性を測定する。

1. RIB-INコンバージェンス

2. RIB-OUTコンバージェンス

3. eBGPコンバージェンス

4. iBGP コンバージェンス

5.1.1. RIB-INコンバージェンス

目的: このテストは、BGPを使用して経路を受信し、RIBにインストールするのにかかるコンバージェンス時間を測定する。

参照テストのセットアップ: このテストでは、図1に示すセットアップを使用する。

手順:
A. コンバージェンスに影響を与えるすべての変数は、基本的なテスト状態(セクション4.4で定義)に設定する必要がある。

B. DUTとエミュレータの1つのピアEmp1間でBGP隣接関係を確立する。

C. 隣接関係を確実に確立するため、残りのテストに進む前に、DUTから3つのキープアライブを受信するか、設定可能な遅延を待つ。

D. 経路ミックスで指定された経路(例えば、routeA)をターゲットに、エミュレータtxからDUTに向けてトラフィックを開始する。初期状態では、RouteAはDUTの転送データベースにインストールされていないため、出力インタフェースでトラフィックが観測されない(SHOULD)。

E. ピア(Emp1)からDUTに経路Aを広告し、時間を記録する。

これはTup(Emp1,Rt-A)であり、XMT-Rt-time(Rt-A)とも呼ばれる。

F. Emp1からの経路Aが DUTで受信された時間を記録する。

これは Tup(DUT,Rt-A)であり、RCV-Rt-time(Rt-A)とも呼ばれる。

G. 経路Aをターゲットにしたトラフィックが、エミュレータによって適切なトラフィックの出力インタフェースで受信された時間を記録する。

これはTR(TDr,Rt-A)であり、DUT-XMT-Data-Time(Rt-A)とも呼ばれる。

H. Tup(DUT,RT-A)とトラフィック受信時間(TR (TDr, Rt-A)の差)は、経路ミックスにおける経路AのFIB ンバージェンス時間である。経路アップデートの完全なコンバージェンスは、最初の経路(Rt-A)と最後の経路(Rt-last)の間の測定時間である。

経路アップデートのコンバージェンスは

TR(TDr, Rt-last)- Tup(DUT, Rt-A)、または

(DUT-XMT-Data-Time - RCV-Rt-Time)(Rt-A).

注: 同じ経路ミックスを使用した1回のテストを数回繰り返すことが推奨される。レポートには、すべてのテストの標準偏差と平均が記載する必要がある。

さまざまな数の経路と経路ミックスでテストを実行することは、1つのピアの完全な特性を把握するために重要である。

5.1.2. RIB-OUT コンバージェンス

目的: このテストは、実装がBGPを使用して経路を受信し、インストールし、広告するのにかかるコンバージェンス時間を測定する。

参照テストのセットアップ: このテストでは、図2に示すセットアップを使用する。

手順:
A. ヘルパー・ノード(HLP)は、DUTと同じバージョンのBGPを実行しなければならない(MUST)。

B. すべてのデバイスはNTPまたは何らかのローカル基準クロックを使って同期されなければならない(MUST)。

C. ヘルパー・ノード、DUT、およびエミュレータのすべての設定変数は、同じ値に設定する必要がある(SHOULD)。これらの値は、基本テスト値であってもよいし、テスト設定で完全に記述された固有の設定値であってもよい。

D. DUTとエミュレータ間にBGP隣接関係を確立する。

E. DUTとヘルパー・ノード間にBGP隣接関係を確立する。

F. 隣接関係を確実に確立するには、テストの残りの部分に進む前に、DUTから3つのキープアライブを受信するか、設定可能な遅延を待つ。

G. エミュレータから特定の経路(例えば、経路A)をターゲットとするヘルパー・ノードに向かうトラフィックを開始する。初期状態では、経路AがDUTの転送データベースにインストールされていないため、出力インタフェース上でトラフィックが観測する必要はない(SHOULD)。

H. エミュレータからDUTに経路Aを広告し、時間を記録する。

これはTup(EMx, Rt-A)であり、EM-XMT-Data-Time(Rt-A)とも呼ばれる。

I. 経路AがDUTによって受信された時間を記録する。

これはTup(DUTr, Rt-A)であり、DUT-RCV-Rt-Time(Rt-A)とも呼ばれる。

J. DUTによってRouteAがヘルパーノードに転送された時間を記録する。

これはTup(DUTx, Rt-A)であり、DUT-XMT-Rt-Time(Rt-A)とも呼ばれる。

K. 経路AをターゲットとするトラフィックがRoute Egress Interfaceで受信された時間を記録する。これはTR(EMr, Rt-A)であり、DUT-XMT-Data Time(Rt-A)とも呼ばれる。

FIBコンバージェンス = (DUT-XMT-Data-Time -DUT-RCV-Rt-Time)(Rt-A)

RIBコンバージェンス = (DUT-XMT-Rt-Time - DUT-RCV-Rt-Time)(Rt-A)

経路ストリームのコンバージェンスは以下のように特徴付けられる:

a) FIBとRIBの個別の経路コンバージェンス、および

b) 全経路のコンバージェンス

FIBコンバージェンス = DUT-XMT-Data-Time(last) - DUT-RCV-Rt- Time(first)、および

RIBコンバージェンス = DUT-XMT-Rt-Time(last) - DUT-RCV-Rt- Time(first)

5.1.3. eBGPコンバージェンス

目的: このテストは、eBGPシナリオで経路を受信、インストールし、広告するために実装が要したコンバージェンス時間を測定する。

参照テストのセットアップ: このテストでは、図2に示すセットアップを使用し、RIB-INとRIB-OUTで説明したシナリオがこのテストケースに適用される。

5.1.4. iBGPコンバージェンス

目的: このテストは、実装がiBGPシナリオで経路を受信、インストール、広告するのにかかるコンバージェンス時間を測定する。

参照テストのセットアップ: このテストでは、図2に示すセットアップを使用し、RIB-INとRIB-OUTで説明したシナリオがこのテストケースに適用される。

5.1.5. eBGPマルチホップ コンバージェンス

目的: このテストでは、実装がeBGPマルチホップ・シナリオで経路を受信、インストール、広告するのにかかるコンバージェンス時間を測定する。

参照テストのセットアップ: このテストでは、図3に示すセットアップを使用する。DUTはヘルパーノードとともに使用される。

手順:
A. ヘルパーノードはDUTと同じバージョンのBGPを実行する必要しなければならない(MUST)。

B. すべてのデバイスは、NTPまたは何らかのローカル基準クロックを使用して同期させなければならない(MUST)。

C. 認証、ポリシー、タイマーなど、コンバージェンスに影響を及ぼすすべての変数は、基本設定に設定する必要がある(SHOULD)。

D. DUT、エミュレータ、ヘルパーノードの3つのデバイスはすべて、異なるASで構成する。

E. ループバック・インタフェースはDUTとヘルパーノードに構成され、DUTで使用可能な設定オプションを使用して両者間の接続が確立する。

F. DUTとエミュレータ間にBGP隣接関係を確立する。

G. DUTとヘルパーノード間にBGP隣接関係を確立する。

H. 隣接関係を確実に確立するには、DUTから3つのキープアライブを受信するか、設定可能な遅延時間を待ってから、残りのテストに進む。

I. エミュレータからDUTに向かうトラフィックを、特定の経路(例えば、経路A)を対象として開始する。

J. 初期状態では、経路AがDUTの転送データベースにインストールされていないため、出力インタフェースでトラフィックが観測してはならない(SHOULD)。

K. エミュレータからDUTに経路Aを広告し、Route-Tx-time(Rt-A)とも呼ばれる時間Tup(EMx,RouteA)を記録する。

L. DUTが経路を受信した時間を記録する。これはTup(EMr,DUT)であり、Route-Rcv-time(Rt-A)とも呼ばれる。

M. DUTの出力インタフェースから、経路Aに向けたトラフィックを受信した時間をエミュレータに記録する。これは Data-Rcv-time(Rt-A)という名前のTup(EMd,DUT)である。

N. 経路AがDUTによってヘルパーノードに向けて転送される時間を記録する。これはTup(EMf,DUT)であり、Route-Fwd-time(Rt-A) とも呼ばれる。

FIBコンバージェンス = (Data-Rcv-time - Route-Rcv-time)(Rt-A)

RIBコンバージェンス = (Route-Fwd-time - Route-Rcv-time)(Rt-A)

注記: さまざまな数の経路と経路ミックスでテストを繰り返すことが推奨される。それぞれの設定された経路ミックスで、テストを複数回繰り返す必要がある。結果には、平均、中間、標準偏差を記録する。

5.2. BGP障害/コンバージェンス・イベント

5.2.1. DUT側の物理リンク障害

目的: このテストは、DUTのローカル・インタフェースでのローカル・リンク障害イベントによる経路コンバージェンス時間を測定する。

参照テストのセットアップ: このテストは、図1に示すセットアップを使用する。シャットダウン・イベントは、DUT上の管理シャットダウン・イベントとして定義されるえ。

手順:

A. 認証、ポリシー、タイマーなど、コンバージェンスに影響するすべての変数は、basic-testポリシーに設定する必要がある。

B. DUTからエミュレータへの2つのBGP隣接関係を確立する。1つはピア・インタフェース経由で、もう1つは第2のピア・インタフェースを使用する。

C. 優先ネクストホップの最適な出口インタフェースが(Emp1)インタフェースになるように、プリファレンス設定を使用して両方の隣接上で同じ経路routeAを広告する。

D. 隣接関係を確実に確立するには、DUTから3つのキープアライブを受信するか、設定可能な遅延時間を待ってから、残りのテストに進む。

E. エミュレータからDUTに向かうトラフィックを、特定の経路(例えばrouteAなど)をターゲットとして開始する。最初は、トラフィックはEmp2ではなく最適な出力経路Emp1で観測する。

F. DUT(Dp1)上の最適出口インタフェースのシャットダウン・イベントをトリガーとする。この時間をシャットダウン時間と呼ぶ。

G. イベントが検出され、トラフィックが次の最適出口インタフェース(Dp2)に転送されるまでのコンバージェンス時間を測定する。

時間 = データ検出(Emp2) - シャットダウン時間

H. 提供負荷を停止し、キューが空になるまで待つ。データ・フローを再開する。

I. DUTの最低出口インタフェースでリンクを立ち上げる。

J. トラフィックがDp2から最適出口インタフェースDp1に再ルーティングされるのにかかるコンバージェンス時間を測定する。

時間 = データ検出(Emp1) - 起動時間

K. このテストは、経路数と経路ミックスを変えて、あるいは運用ネットワークで展開されているものに近い経路数と経路ミックスを使用して、テストを繰り返すことを推奨する。

5.2.2. リモート/エミュレータ側での物理リンク障害

目的: このテストは、テスターのローカル・インタフェースにおけるローカル・リンク障害イベントによる経路コンバージェンス時間を測定する。

参照テストのセットアップ: このテストでは、図1に示すセットアップを使用する。シャットダウン・イベントは、論理シャットダウン・イベントを介したテスターのローカル・インタフェースのシャットダウンとして定義する。終了にはセクション5.2.1で使用した手順を使用する。

5.2.3. DUT側のECMPリンク障害

目的: このテストは、ECMPメンバーのローカル・リンク障害イベントによる経路コンバージェンス時間を測定する。FIB構成とBGPは、2つのECMP経路をインストールできるように設定されている。しかし、ポリシーにより、経路はどちらか1つのパスでのみ送信されるようにする。

参照テストのセットアップ: このテストでは、図1に示すセットアップとセクション5.2.1で使用した手順を使用する。

5.3. エミュレータでのBGP隣接障害(非物理リンク障害)

目的: このテストは、エミュレータ上のBGP隣接障害による経路コンバージェンス時間を測定する。

参照テストのセットアップ: このテストでは、図1に示すセットアップを使用する。

手順:
A. 認証、ポリシー、タイマーなど、コンバージェンスに影響するすべての変数は、basic-policyに設定する必要がある。

B. DUTからエミュレータへの2つのBGP隣接関係を確立する。1つは最適出口インタフェース経由、もう1つは次の最適出口インタフェースを使用する。

C. 優先ネクストホップの最適な出口インタフェースが(Emp1)インタフェースになるように、プリファレンス設定を使用して両方の隣接上で同じ経路routeAを広告する。

D. 隣接関係を確実に確立するには、DUTから3つのキープアライブを受信するか、設定可能な遅延時間を待ってから、残りのテストに進む。

E. エミュレータからDUTに向かうトラフィックを、特定の経路(例えばrouteAなど)をターゲットとして開始する。最初は、トラフィックはEmp2ではなく最適な出力経路Emp1で観測する。

F. 最適出口インタフェースのエミュレータ上のソフトウェア隣接関係ダウンにより、BGP隣接関係を削除する。この時間はBGPadj-down-timeと呼ばれ、BGPpeer-down とも呼ばれる。

G. イベントが検出され、次の最適出力インタフェースにトラフィックが転送されるまでのコンバージェンス時間を測定する。この時間はTr-rr2で、TR2-traffic-onとも呼ばれる。

コンバージェンス = TR2-traffic-on - BGPpeer-down

H. 提供負荷を停止し、キューが空になるのを待ってデータフローを再開する。

I. 最適出口インタフェースを介して、エミュレータ上でBGP隣接関係を確立する。この時間はBGP-adj-up、あるいはBGPpeer-upと呼ばれる。

J. トラフィックが最適出口インタフェースに再ルーティングされるまでにかかるコンバージェンス時間を測定する。この時間はTr-rr1で、TR1-traffic-onとも呼ばれる。

コンバージェンス = TR1-traffic-on - BGPpeer-up

5.4. BGPハードリセット・テストケース

5.4.1. DUTのBGP非回復ハードリセット・イベント

目的: このテストは、DUTのハードリセットによる経路コンバージェンス時間を測定する。

参照テストのセットアップ: このテストでは、図1に示すセットアップを使用する。

手順:

A. このテストケースの要件は、ハードリセット・イベント回復せず、最適出口インタフェース上のDUTとエミュレータ間の隣接関係のみに影響することである。

B. テストに影響を及ぼすすべての変数は、基本テスト値に設定する必要がある(SHOULD)。

C. DUTからエミュレータへの2つのBGP隣接関係を確立する。1つは最適出口インタフェースを使用し、もう1つは次の最適出口インタフェースを使用する。

D. 優先ネクストホップの最適出口インタフェースが(Emp1)インタフェースになるように、優先設定を使用して両隣接上で同じ経路routeAを広告する。

E. 隣接関係を確実に確立するには、DUTから3つのキープアライブを受信するか、設定可能な遅延時間を待ってから、残りのテストに進む。

F. エミュレータからDUTに向かうトラフィックを、特定の経路(例えばrouteAなど)をターゲットとして開始する。最初は、トラフィックは最適出口インタフェース上で観測する。

G. DUTの最適出口インタフェースのハードリセット・イベントをトリガーする。この時間をタイムリセット(time-reset)と呼ぶ。

H. このイベントが検出され、トラフィックが次の最適出口インタフェースに転送され流。この時間をタイム・トラフィック・フロー(time-traffic flow)と呼ぶ。

I. イベントが検出され、トラフィックが次の最適出口インタフェースに転送されるまでのコンバージェンス時間を測定する。

コンバージェンス時間 = time-traffic flow - time-reset

J. 提供された負荷を停止し、キューが空になって再起動されるのを待つ。

K. このテストは、経路数と経路ミックスを変えて、あるいは運用ネットワークで展開されているものに近い経路数と経路ミックスを使用して、テストを繰り返すことを推奨する。

L. さまざまな数の経路を使用する場合、コンバージェンス時間は損失導出法(Loss-Derived method)[RFC6412]を使用して測定する。

M. このシナリオのコンバージェンス時間は、テスターでの障害検出時間、BGPキープアライブ時間とルーティング、フォワーディング・テーブルの更新時間に影響する。

5.5. BGPソフトリセット

目的: このテストは、実装がBGP経路リフレッシュ・メッセージに対応し、経路を広告するためにかかる経路コンバージェンス時間を測定する。

参照テストのセットアップ: このテストでは、図2に示すセットアップを使用する。

手順:

A. DUTおよびヘルパーノード上のBGP実装は、BGP経路リフレッシュ機能[RFC2918]をサポートする必要がある。

B. すべてのデバイスは、NTPまたは何らかのローカル基準クロックを使用して同期しなければならない(MUST)。

C. 認証、ポリシー、タイマーなど、コンバージェンスに影響を与えるすべての変数は、basic-testのデフォルトに設定する必要がある。

D. DUTとヘルパーノードは同じASに設定されているが、エミュレータは別のASに設定されている。

E. DUTとエミュレータ間にBGP隣接関係を確立する。

F. DUTとヘルパーノード間にBGP隣接関係を確立する。

G. 隣接関係を確実に確立するには、DUTから3つのキープアライブを受信するか、設定可能な遅延時間を待ってから、残りのテストに進む。

H. ヘルパーノードのBGPの下に、DUTから受信した経路を拒否するポリシーを設定する。

I. エミュレータからDUTにrouteAを広告する。

J. DUTはヘルパーノードへの経路を広告しようとするが、拒否されるだろう。

K. 3回のキープアライブを待つ。

L. エミュレータから、特定の経路(例えば、routeA)をターゲットとしたヘルパーノードに向かうトラフィックを開始する。最初は、routeAが存在しないので、出口インタフェースではトラフィックは観測されない。

M. ヘルパーノードのポリシーを削除し、DUTに向けて経路リフレッシュ要求を発行する。このイベントのタイムスタンプに注意する。これがリフレッシュ時間(RefreshTime)である。

N. routeAをターゲットとしたトラフィックが出口インタフェースで受信した時間を記録する。これがRecTimeである。

O. 経路ごとの経路リフレッシュ・コンバージェンス時間を以下の式で表す。

経路リフレッシュ・コンバージェンス時間 = (RecTime - RefreshTime)

5.6. BGP経路の取り消しコンバージェンス時間

目的: このテストは、実装がBGP取り消しメッセージを処理し、取り消しを広告するのにかかる経路コンバージェンス時間を測定する。

参照テストのセットアップ: このテストは、図2に示すセットアップを使用する。

手順:

A. このテストは、合計取り消し処理時間を決定する2つのステップで構成される。

B. ステップ 1:

(1) すべてのデバイスは、NTPまたは何らかのローカル基準クロックを使用して同期させなければならない。

(2) すべての変数は基本テスト・パラメータに設定する必要がある。

(3) DUTとヘルパーノードは同じASに設定し、エミュレータは別のASに設定する。

(4) DUTとエミュレータの間にBGP隣接関係を確立する。

(5) 隣接関係を確実に確立するには、DUTから3つのキープアライブを受信するか、設定可能な遅延時間を待ってから、残りのテストに進む。

(6) エミュレータから、特定の経路(例えば、routeA)をターゲットとしたヘルパーノードに向かうトラフィックを開始する。最初は、routeAが存在しないので、出口インタフェースではトラフィックは観測されない。

(7) エミュレータからDUTにrouteAを広告する。

(8) routeAをターゲットとしたトラフィックが出口インタフェースで受信する。

(9) ここで、テスターからDUTにrouteAの取り消し要求を送信する。TRx(Awith)はWdrawTime1(Rt-A)とも呼ばれる。

(10) エミュレータが判断したトラフィックが観察されない時間を記録する。これはRouteRemoveTime1(Rt-A)である。

(11) RouteRemoveTime1とWdrawTime1の差をWdrawConvTime1とする。

WdrawConvTime1(Rt-A) = RouteRemoveTime1(Rt-A) - WdrawTime1(Rt-A)

C. ステップ2:

(1) ステップ1から続け、テスターからDUTにrouteAを再広告する。

(2) DUTは、routeAをヘルパーノードに広告しようとする(これは、DUTとヘルパーノード間にセッションが存在することを前提とする)。

(3) 特定の経路(例えば、routeA)をターゲットとし、エミュレータからヘルパーノードに向けてトラフィックを開始する。routeAがヘルパーノードによって受信された後、トラフィックは出口インタフェースで観測される。

WATime=トラフィックが最初に流れる時間

(4) ここで、テスタはDUTにrouteAの取り消し要求を送る。これが WdrawTime2(Rt-A)である。

WAWtime-TRx(Rt-A) = WdrawTime2(Rt-A)

(5) DUTは取り消しを処理し、ヘルパーノードに送信する。

(6) エミュレータが判断したトラフィックが観測されない時間を記録する。これは、

TR-WAW(DUT,RouteA) = RouteRemoveTime2(Rt-A)

(7) 合計取り消し処理時間は以下のとおりである。

TotalWdrawTime(Rt-A) = ((RouteRemoveTime2(Rt-A) - WdrawTime2(Rt-A)) - WdrawConvTime1(Rt-A))

5.7. BGPパス属性変更のコンバージェンス時間

目的: このテストは、実装がBGPパス属性の変更に対応するのにかかるコンバージェンス時間を測定する。

参照テストのセットアップ: このテストでは、図1に示すセットアップを使用する。

手順:

A. このテストは、オリジン、ASパス、ネクストホップのような周知必須属性にのみ適用する。

B. テストの各反復において、これらの必須属性のうち1つだけを変化させる必要があり、他の属性は同じままである。

C. すべてのデバイスは、NTPまたは何らかのローカル基準クロックを使用して同期させなければならない(MUST)。

D. すべての変数をbasic-testパラメータに設定する必要がある。

E. 優先ネクストホップの最適な出口インタフェースが(Emp1)インタフェースになるように、プリファレンス設定を使用して両方の隣接上で同じ経路routeAを広告する。

F. 隣接関係を確実に確立するには、DUTから3つのキープアライブを受信するか、設定可能な遅延時間を待ってから、残りのテストに進む。

G. 特定の経路(例えば、routeA)をターゲットとしたDUTに向けたエミュレータからのトラフィックを開始する。初めは、トラフィックは最適な出口インタフェースで観測される。

H. ここで、同じ経路、routeAを次に最適な出口インタフェースに広告するが、周知必須属性の1つを変更して、そのインタフェースよりも優先される値を持つようにする。これをTbetterと呼ぶ。他の値は、最適出口隣接関係で広告された値と同じ必要がある。

TRx(Path-Change(Rt-A)) = Path Change Event Time(Rt-A)

I. イベントが検出され、トラフィックが次に最適な出口インタフェースに転送されるまでのコンバージェンス時間を測定する。

DUT(Path-Change, Rt-A) = Path-switch time(Rt-A)

コンバージェンス = Path-switch time(Rt-A) - Path Change Event Time(Rt-A)

J. 提供された負荷を停止し、キューが空になって再起動されるまで待つ。

K. さまざまな属性についてテストを繰り返す。

5.8. BGPグレースフル・リスタートのコンバージェンス時間

目的: このテストでは、用語集文書[RFC4098]で詳細に説明されているように、グレースフル・リスタート・イベント中に実装に要した経路コンバージェンス時間を測定する。

参照テストのセットアップ: このテストでは、図4に示すセットアップを使用する。

手順:

A. 実装がBGPグレースフル・リスタート・イベントを処理し、経路を広告するのにかかる時間を測定する。

B. ヘルパーノードはDUTと同じモデルであり、DUTと同じBGP実装を実行する。

C. DUTおよびヘルパーノード上のBGP実装は、BGPグレースフル・リスタート・メカニズム[RFC4724]をサポートする必要がある。

D. すべてのデバイスは、NTPまたは何らかのローカル基準クロックを使って同期させなければならない(MUST)。

E. すべての変数はbasic-test値に設定する。

F. DUTとヘルパーノード1(HLP1)は同じASに設定され、エミュレータとヘルパーノード2(HLP2)は異なるASに設定する。

G. DUTとヘルパーノード間にBGP隣接関係を確立する。

H. ヘルパー ード2とエミュレータ間にBGP隣接関係を確立する。

I. 隣接関係を確実に確立するには、DUTから3つのキープアライブを受信するか、設定可能な遅延時間を待ってから、残りのテストに進む。

J. DUTから受信した経路を拒否するために、ヘルパーノード1のBGPでポリシーを設定する。

K. エミュレータからヘルパーノード2にrouteAを広告する。

L. ヘルパーノード2はDUTに経路を広告し、DUTはその経路をヘルパーノード1に広告しようとするが、拒否される。

M. キープアライブを3回待つ。

N. 特定の経路(例えば、routeA)をターゲットとしたヘルパーノード1に向けたトラフィックを開始する。初めは、routeAが存在しないため、出口インタフェースにトラフィックは観測されない。

O. DUTでグレースフル・リスタート・トリガー・イベントを実行し、時間を記録する。これがGREventTimeである。

P. ヘルパーノード1のポリシーを削除する。

Q. 出口インタフェースでrouteA宛てのトラフィックを受信した時間を記録する。

これはTRr(DUT,routeA)であり、RecTime(Rt-A)とも呼ぶ。

R. 次の式は、グレースフル・リスタートのコンバージェンス時間を表す。

グレースフル・リスタートの収束時間(Rt-A) = ((RecTime(Rt-A) - GREventTime) - RIB-IN)

S. このテストケースでは、DUTでスイッチオーバーがトリガーされた後、BGPリフレッシュ・メッセージを処理するサイクルが存在しないと想定している。この想定の理由は、スイッチオーバー後、ヘルパーノード1からポリシーを削除するとき、実装が自動的に経路リフレッシュを生成する可能性があり、DUTが実際にスイッチオーバーしてピアとのBGP隣接関係を再確立する前に、この要求が処理される可能性がある限られたウィンドウが存在するためである。

6. 報告フォーマット

各テストケースについて、以下の報告表を完成させることが推奨され、すべての時間値は[RFC4098]で規定されている解像度で報告する必要がある(SHOULD)。

パラメータ	単位または説明
テストトポロジ	1、2、3、または 4
並列リンク	並列リンク数
インタフェースの種類	ギガビット・イーサネット (GigE)、Packet over SONET(POS)、ATM、その他
コンバージェンス・イベント	ハードリセット、ソフトリセット、リンク障害、またはその他の定義
eBGP セッション	eBGPのセッションの数
iBGP セッション	iBGPのセッション数
eBGP ネイバー	eBGPのネイバー数
iBGP ネイバー	iBGPのネイバー数
ピアごとの経路	経路数
ユニークな総経路数	経路数
非・ユニークな総経路数	経路数
IGPの設定	IS-IS、OSPF、スタティック、またはその他
経路ミックス	経路ミックスの説明
経路パッキング	アップデートに含まれる経路数
ポリシーの設定	イエス、ノー
SIDRオリジン認可 [RFC7115]	イエス、ノー
bgp-sec [BGPsec]	イエス、ノー
DUTに提供されるパケットサイズ	バイト
提供負荷	パケット/秒
テスター上のパケットサンプリング間隔	秒
転送遅延しきい値	秒
DUTで設定されたタイマー値
インターフェース障害の表示遅延	秒
ホールド時間	秒
MinRouteAdvertisingInterval (MRAI)	秒
MinASOriginationInterval (MAOI)	秒
キープアライブ時間	秒
接続再試行	秒
DUTとテスターのTCPパラメーター
最大セグメントサイズ (MSS)	バイト
スロースタートのしきい値	バイト
最大ウィンドウ・サイズ	バイト

テストの詳細:
ａ. 提供負荷が経路のサブセットと一致する場合、このサブセットがどのように選択されるかを説明する。

b. コンバージェンス・イベントがどのように適用されるかを説明する。即座にトラフィック損失が発生するかどうか?

c. ポリシーが設定されている場合、設定されているポリシーを記述する。

初期コンバージェンス・イベントと復帰コンバージェンス・イベントについて、以下の表を完成させる。

パラメータ	単位
コンバージェンス・イベント	初期または復帰
トラフィック転送指標
DUTに提供される総パケット数	パケット数
DUT によって転送される総パケット数	パケット数
接続パケット損失	パケット数
コンバージェンス・パケット損失	パケット数
順不同パケット	パケット数
重複パケット	パケット数
コンバージェンスのベンチマーク
レート導出法 [RFC6412]:
最初のルートの収束時間	秒
完全なコンバージェンス時間	秒
損失導出法 [RFC6412]:
損失導出コンバージェンス時間	秒
ルート固有 (R-S) 損失派生方法
最小R-Sコンバージェンス時間	秒
最小R-Sコンバージェンス時間	秒
最大R-Sコンバージェンス時間	秒
R-Sコンバージェンス時間の中央値	秒
平均 R-Sコンバージェンス時間	秒
接続喪失(LoC)ベンチマーク
損失導出法:
損失由来の接続期間の損失	秒
経路固有の損失派生方法:
最小LoC期間[n]	秒の配列
最小経路LoC期間	秒
最大経路LoC期間	秒
中央経路LoC期間	秒
平均経路LoC期間	秒

7. セキュリティに関する考慮事項

本文書に記載されているベンチマーク活動は、専用のアドレス空間と上記のセクションで指定された制約を備えた実験室環境における制御された刺激を使用した技術特性評価に限定される。

ベンチマーク用ネットワーク・トポロジは独立したテスト・セットアップであり、テスト・トラフィックを運用ネットワークに転送したり、トラフィックをテスト管理ネットワークに誤ってルーティングしたりする可能性のあるデバイスに接続してはならない(MUST NOT)。

さらに、ベンチマークは「ブラックボックス」ベースで実行され、DUT/SUTの外部で観測可能な測定値のみに依存する。

特にベンチマークを目的とした特別な機能がDUT/SUTに存在すべきではない(SHOULD NOT)。DUT/SUTに起因するネットワーク・セキュリティへの影響は、ラボと実稼働ネットワークで同一である必要がある(SHOULD)。

8. 参考文献

8.1. 引用規格

秒 IEEE, "IEEE Standard for Information technology -- Telecommunications and information exchange between systems Local and metropolitan area networks -- Specific requirements Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications", IEEE 802.11-2012, DOI 10.1109/ieeestd.2012.6178212, April 2012, <http://ieeexplore.ieee.org/servlet/ opac?punumber=6178209>.

[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.

[RFC2918] Chen, E., "Route Refresh Capability for BGP-4", RFC 2918, DOI 10.17487/RFC2918, September 2000, http://www.rfc-editor.org/info/rfc2918.

[RFC4098] Berkowitz, H., Davies, E., Ed., Hares, S., Krishnaswamy, P., and M. Lepp, "Terminology for Benchmarking BGP Device Convergence in the Control Plane", RFC 4098, DOI 10.17487/RFC4098, June 2005, http://www.rfc-editor.org/info/rfc4098.

[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006, http://www.rfc-editor.org/info/rfc4271.

[RFC6412] Poretsky, S., Imhoff, B., and K. Michielsen, "Terminology for Benchmarking Link-State IGP Data-Plane Route Convergence", RFC 6412, DOI 10.17487/RFC6412, November 2011, http://www.rfc-editor.org/info/rfc6412.

8.2. 参考規格

[BGPsec] Lepinski, M. and K. Sriram, "BGPsec Protocol Specification", Work in Progress, draft-ietf-sidr-bgpsec-protocol-15, March 2016.

[RFC1242] Bradner, S., "Benchmarking Terminology for Network Interconnection Devices", RFC 1242, DOI 10.17487/RFC1242, July 1991, http://www.rfc-editor.org/info/rfc1242.

[RFC1983] Malkin, G., Ed., "Internet Users' Glossary", FYI 18, RFC 1983, DOI 10.17487/RFC1983, August 1996, http://www.rfc-editor.org/info/rfc1983.

[RFC2285] Mandeville, R., "Benchmarking Terminology for LAN Switching Devices", RFC 2285, DOI 10.17487/RFC2285, February 1998, http://www.rfc-editor.org/info/rfc2285.

[RFC2545] Marques, P. and F. Dupont, "Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing", RFC 2545, DOI 10.17487/RFC2545, March 1999, http://www.rfc-editor.org/info/rfc2545.

[RFC4724] Sangli, S., Chen, E., Fernando, R., Scudder, J., and Y. Rekhter, "Graceful Restart Mechanism for BGP", RFC 4724, DOI 10.17487/RFC4724, January 2007, http://www.rfc-editor.org/info/rfc4724.

[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, DOI 10.17487/RFC4760, January 2007, http://www.rfc-editor.org/info/rfc4760.

[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication Option", RFC 5925, DOI 10.17487/RFC5925, June 2010, http://www.rfc-editor.org/info/rfc5925.

[RFC6414] Poretsky, S., Papneja, R., Karthik, J., and S. Vapiwala, "Benchmarking Terminology for Protection Performance", RFC 6414, DOI 10.17487/RFC6414, November 2011, http://www.rfc-editor.org/info/rfc6414.

[RFC7115] Bush, R., "Origin Validation Operation Based on the Resource Public Key Infrastructure (RPKI)", BCP 185, RFC 7115, DOI 10.17487/RFC7115, January 2014, http://www.rfc-editor.org/info/rfc7115.

謝辞

アニル・タンドン、アルヴィンド・パンデイ、モハン・ナンドゥリ、ジェイ・カーティク、およびエリック・ブレンデルらの本文書のさまざまなセクションについての意見や議論に感謝する。また、ウィル・リュー、ヒューバート・ギー、セミョン・リシャンスキー、ファイサル・シャーらの本文書のレビューとフィードバックに感謝する。

著者のアドレス

ラジブ・パプネジャ
Huawei Technologies
メール: [e-mail]

ババニ・パリセ
Skyport Systems
メール: [e-mail]

スーザン・ヘアズ
Huawei Technologies
メール:[e-mail]

ディーン・リー
IXIA
メール: [e-mail]

イリヤ・ヴァラシキン
Google
メール：[e-mail]

変更履歴

• 2024.3.20