🦔

RFC 4098: コントロール・プレーンにおけるBGPデバイスのコンバージェンスのベンチマークに関する用語

2024/03/20に公開

RFC

bgp

tech

本文書の位置付け

本文書は、インターネット・コミュニティに向け、情報を提供する。いかなる種類のインターネット標準を指定するものではない。本文書の配布は無制限である。

著作権表示

著作権 (C) The Internet Society (2005)。

要旨

本文書は、1台のBGPデバイスのコントロール・プレーンにおけるeBGPのコンバージェンス(収束)を測定するためのベンチマーク方法の説明を標準化するための用語を確立する。将来の文書では、iBGPコンバージェンス、集中型コントロール・プレーン情報に基づく転送の開始、および相互作用する複数のBGPデバイスを取り上げる予定である。この用語は、IPv4とIPv6の両方に適用される。各バージョンの実例は、関連する箇所に記載されている。

1. はじめに

本文書では、ルータまたはBGP機能をインスタンス化する他のデバイスにおけるBGPプロセスのコンバージェンス性能を特徴付けるために使用する用語を定義する。(文書の残りの部分でRFC 1771と参照される、「ボーダー・ゲートウェイ・プロトコル4 (BGP-4)」[RFC1771]を参照。) これは2つの文書シリーズの最初の部分であり、後続の文書には関連するテストと方法論が含まれる。この用語は、IPv4とIPv6の両方に適用される。各バージョンの実例は、関連する箇所に記載されている。ただし、本文書は主にIPv4ネットワークのBGP-4を対象としている。IPv6では、RFC 2545[RFC2545]で説明しているように、MP-BGP[RFC2858]を使用する必要があるが、本文書ではBGP-4の拡張機能に固有の用語や問題については扱わない。また、RFC 2547[RFC2547]で説明されているVPNをサポートするBGPの拡張機能に特有の用語や問題も、この文書の範囲外である。

本文書および付属文書で採用されたアプローチの基礎には、以下の見解(observations)がある:

主な目的は、BGPのコンバージェンス関連測定の実施と報告を標準化する方法論を導き出すことである。
これらの測定の文脈で頻繁に使用される多くの用語から曖昧さを取り除く必要がある。
コンバージェンスの特性評価は複雑なプロセスであるため、この一連の文書では、BGPコンバージェンスを特性評価する最初の段階として、基本的なコントロール・プレーンの測定方法を規定することに最初の焦点を絞ることが望ましい。

そのため、BGPのようなパス・ベクトル型プロトコルでは、ルーティング情報の到着、処理、伝播からなるネットワークとシステム・コントロール・プレーン[RFC3654]のアクティビティに最初の主眼を置く。

テストの目的上、すべてのオプションのパラメータをオフにする必要がある(SHOULD)ことに留意する。テストで別段の指定がない限り、すべての変数パラメータはデフォルト設定の必要がある(SHOULD)。

後続の文書では、BGP-4のマルチプロトコル拡張の存在、ポリシー処理、テスト対象デバイス(DUT)内の制御パスとデータパス上の同時トラフィック、その他の現実的な性能変更要因(performance modifiers)の影響など、コンバージェンス測定のより複雑な側面についても検討する予定である。内部ゲートウェイ・プロトコル(IGP)のコンバージェンスについても、別の文書で検討する。

1.1. 概要とロードマップ

デバイスのBGPコンバージェンス性能の特性評価は、BGP機能性のすべての明確なステージと特徴を考慮に入れなければならない。これには、関連する用語と指標を可能な限り具体的に定義する必要がある。このような定義が本文書の目的である。

必要な定義は別のカテゴリに分類されます。

ルーティング情報の構成要素と特徴
ルーティングのデータ構造と経路のカテゴリ
コンバージェンス中のネットワークまたはルータの構成要素の説明
一連のアップデート・メッセージ、経路変更イベントのタイプ、およびBGPの運用に特有のイベントの特徴
コンバージェンス処理の性能に影響を与える要因の説明

1.2. 定義フォーマット

定義フォーマットは、「IPバージョン4ルータの要件」[RFC1812]で定義されているものと同等であり、便宜上ここで繰り返す:

X.x 定義する用語(例: レイテンシ)。

定義: 定義の本文を形成する1つ以上の文。

考察: 用語、その適用、測定手順に関する制限事項についての簡単な説明。

測定単位: この用語の測定値を報告するために使用される単位。この項目は適用されない場合がある(N.A.)。

問題点: この用語に影響を及ぼす可能性のある問題または条件のリスト。

関連項目: この用語の定義または考察に関連する関連用語のリスト。

2. ルーティング情報の構成要素と特徴

2.1. (ネットワーク)プレフィックス

定義: 「ネットワーク・プレフィックスとは、アドレスの上位にある連続したビットの集合で、ネットワーク内のシステム群を総称して指定するものである。ホスト番号によって、それらのシステムの中から選択する。」 (この定義は、RFC 1812のセクション2.2.5.2「クラスレス・ドメイン間ルーティング(CIDR)」からそのまま引用している。)

考察: CIDRの文脈では、ネットワーク・プレフィックスとは、IPアドレスのネットワーク構成要素である。IPv4システムでは、完全なアドレスのネットワーク構成要素は「ネットワーク部」と呼ばれ、アドレスの残りの部分は「ホスト部」と呼ばれる。IPv6システムでは、完全なアドレスのネットワーク構成要素は「サブネット・プレフィックス」と呼ばれ、残りの部分は「インタフェース識別子」と呼ばれる。

測定単位: N.A.

問題点:

関連項目:

2.2. ネットワーク・プレフィックス長

定義: ネットワーク・プレフィックス長は、アドレス・フィールドを構成する全ビットのうち、アドレスのネットワーク・プレフィックス部分を定義するビット数である。

議論: この構成要素を伝達するためにビット単位のマスクを使う一般的な代替手段は、スラッシュ(/)表記を使うことである。これは、ビット単位のネットワーク・プレフィックス長の概念をIPアドレスに結び付けるものである。例えば、141.184.128.0/17は、このIPv4アドレスのネットワーク構成要素が17ビット幅であることを示す。同様の表記は、IPv6ネットワーク・プレフィックスにも使用する(例: 2001:db8:719f::/48)。アドレスのグループを指す場合、ネットワーク・プレフィックス長は、アドレスのグループを等価クラスとして記述する手段として使われることが多い。例えば、「100件の/16アドレス」は、ネットワーク・プレフィックス長が16ビットの100件のアドレスを指す。

測定単位: ビット

問題点:

関連項目: ネットワーク・プレフィックス

2.3. 経路

定義: 一般的に、「経路」はnタプル「<プレフィックス, ネクストホップ[, 他のルーティングまたは非・ルーティング・プロトコル属性]>」である。経路はエンドツーエンドではなく、プレフィックスで定義された宛先に向かう次の段階でパケットを送るべき特定のネクストホップに関して定義される。この用法では、経路はルーティング・プロトコルから抽出された目的となる宛先に関する情報の基本単位である。

考察: この用語は、すべてのルーティング・プロトコルに共通の経路の概念を指す。上記の定義を参照すると、典型的な非・ルーティング・プロトコルの属性は、diffservやトラフィック・エンジニアリングに関連付けられる。

測定単位: N.A.

問題点: なし

関連項目: BGP経路

2.4. BGP経路

定義: BGP経路は、nタプル「 <プレフィックス, ネクストホップ, ASパス[, その他のBGP属性]>」である。

考察: ネクストホップやASパスなどのBGP属性はRFC 1771で定義されており、パス属性として知られ、経路を定義する修飾データ(qualifying data)である。RFC 1771より: 「このプロトコルの目的上、経路は宛先へのパスの属性を対にした情報の単位として定義される。」

測定単位: N.A.

問題点:

関連項目: 経路、プレフィックス、Adj-RIB-In、ネットワーク・レベル到達性情報 (NLRI)

2.5. ネットワーク・レベル到達性情報 (NLRI)

定義: NLRIは、同じパス属性を持つ1つ以上のネットワーク・プレフィックスで構成される。

考察: NLRIの各プレフィックスは、(共通の)パス属性と合わせ、BGP経路を形成する。NLRIは、パス属性で記述された共通の経路に沿って(ネットワーク内のこのポイントから)パケットをルーティングできる一連の宛先をカプセル化する。

測定単位: N.A.

問題点:

関連項目: 経路パッキング、ネットワーク・プレフィックス、BGP経路、NLRI

2.6. BGP UPDATEメッセージ

定義: UPDATEメッセージは、1つのNLR フィールドの広告が含まれ、複数のプレフィックスと、不適格(unfeasible)経路の複数の撤回(withdrawals)を含む。詳細は、RFC 1771を参照のこと。

考察: RFC 1771より: 「パス属性の可変長シーケンスはすべてのUPDATEに存在する。各パス属性は可変長の3つの<属性タイプ, 属性長, 属性値>である。」

測定単位: N.A.

関連項目:

3. ルーティングのデータ構造と経路のカテゴリ

3.1. ルーティング情報ベース(RIB)

RIBは、論理的に(物理的に必ずしも必要ではない)異なるデータベース・セットから構成され、それぞれを以下に列挙する。RIBには、ルータが転送できるすべての宛先プレフィックスと、それらに対する現在到達可能な1つ以上のネクストホップ・アドレスを含む。

このセットに含まれる経路は、ハードウェアの状態、内部ルーティング・プロトコル、外部ルーティング・プロトコルなど、いくつかの情報源から選択された可能性がある。RFC 1812は、全送信元との関連の中で経路選択基準の基本セットを含む。多くの実装は追加の基準を課している。一般的な実装固有の基準として、ルーティング情報源に与えられる優先順位である。

3.1.1. Adj-RIB-InとAdj-RIB-Out

定義: Adj-RIB-InとAdj-RIB-Outは、個々のピア・ルータの観点から見たルーティング情報「一覧」(views)である。Adj-RIB-Inには、特定のピアからDUTに広告された情報が含まれている。

Adj-RIB-Outには、DUTがピアに広告する情報が含まれている。RFC 1771を参照のこと。

考察:

問題点:

測定単位: 経路インスタンスの数

関連項目: 経路、BGP経路、経路インスタンス、Loc-RIB、FIB

3.1.2. Loc-RIB

定義: Loc-RIBは、ローカル・ポリシーとBGP経路選択アルゴリズムを適用した後、さまざまなAdj-RIBから選択された最適経路の集まりを含む。

考察: さまざまなRIBを暗黙に区別しているのは論理上のものである。どのような実装においても、これらのRIBが別個の独立したエンティティであるとは必ずしも限らない。考慮する必要がある経路タイプには、内部BGP、外部BGP、インタフェース、スタティック、IGP経路などがある。

問題点:

測定単位: 経路数

関連項目: 経路、BGP経路、経路インスタンス、Adj-RIB-In、Adj-RIB-Out、FIB

3.2. プレフィックス・フィルタリング

定義: プレフィックス。フィルタリングは、BGP経路のネットワーク・プレフィックスをネットワーク・プレフィックスのリストと照合することで、RIBへのエントリの候補から経路を除外する技術である。

考察: リストにあるフィルタ・プレフィックスについて、経路プレフィックス長がフィルタ・プレフィックス長以上で、2つのプレフィックスの最上位ビットがフィルタ・プレフィックス長以上一致する場合にBGP経路が削除される。使用例については、「BGP-4の協調経路フィルタリング機能」[BGP-4]を参照のこと。

測定単位: フィルタ・プレフィックスの数、プレフィックス長

問題点:

関連項目: BGP経路、ネットワーク・プレフィックス、ネットワーク・プレフィックス長、ルーティング・ポリシー、ルーティング・ポリシー情報ベース

3.3. ルーティング・ポリシー

定義: ルーティング・ポリシーは、「広告で受け取った経路の受け入れ、拒否、変更のための条件を定義する機能」である[GLSSRY]。

考察: RFC 1771はさらに、ポリシーがホップ・バイ・ホップのルーティング・パラダイム内に収まるように制約している。ポリシーは、プレフィックス・フィルタリングのようなフィルタと関連するポリシー・アクションを使用して実装する。多くのASは、ルーティング・ポリシー仕様言語(RPSL)[RFC2622]を使用して、ポリシーを策定・文書化し、ルータ内のBGPプロセスの設定をRPSL仕様から自動的に生成する。

測定単位: ポリシーの数、ポリシーの長さ

問題点:

関連項目: ルーティング・ポリシー情報ベース、プレフィックス・フィルタリング

3.4. ルーティング・ポリシー情報ベース

定義: ルーティング・ポリシー情報ベースは、受信ポリシーと送信ポリシーの集まりである。

考察: 以下のBGP選択プロセスのフェーズへのすべての言及は、これらのフェーズのRFC 1771の定義に基づいて行われる。受信ポリシーは、BGP選択プロセスのフェーズ1でAdj-RIB-In経路に適用され、フェーズ2の決定プロセスのメトリックを設定する。送信ポリシーは、BGPプロセスのフェーズ3で、特定のピアへの経路(プレフィックスとパス属性タプル)アナウンスの前に、Adj-RIB-Out経路に適用される。ポリシー情報ベースのポリシーには、一致条件とアクション条件がある。一致する一般的な情報は、経路プレフィックス、ASパス、コミュニティなどが含まれる。一致した場合のアクションは、更新を削除してLoc-RIBに渡さないか、あるいはローカル・プリファレンス(入力時)やMED(出力時)の変更、コミュニティの追加や削除、ASパス内の現在のASのプリペンドなど、何らかの方法でUPDATEを変更する。ポリシー処理の量(ルートマップとフィルタ/アクセス・リストの両方の観点から)は、分散BGPアルゴリズムのコンバージェンス時間と特性に影響を与える。ポリシー処理の量は、すべての経路を受け入れ、それに従って送信する単純なポリシーから、プレフィックスの大部分がフィルタ/アクセス・リストによってフィルタリングする複雑なポリシーまでさまざまである。

測定単位: ポリシーの数と長さ

問題点:

関連項目:

3.5. フォワーディング情報ベース (FIB)

定義: RIPE-37[RIPE37]の付録Bの定義によれば、「IPデータグラムを転送するために必要な情報を含むテーブルは、フォワーディング情報ベースと呼ばれる。これには、少なくとも、到達可能な各宛先ネットワーク・プレフィックスのインタフェース識別子とネクストホップ情報を含む。」

考察: フォワーディング情報ベースは、ネットワーク・プレフィックスとルータ・ポート識別子のインデックスを作成したデータベースを言い表す。フォワーディング情報ベースは、ルーティング・ピアから受信したすべてのルーティング情報を保持する「ルーティング・テーブル」(ルーティング情報ベースまたはRIB)とは異なる。これはデータ・プレーンの構造であり、各パケットの転送に使用される。フォワーディング情報ベースはRIBから生成される。本文書の目的にとって、FIBは事実上、パケットごとの転送先を決定するためにフォワーディング・プレーンが使用するRIBのサブセットである。現在の実装のほとんどは、ルータ・インタフェースごとに完全な、非・キャッシュFIBを持っている。すべての経路計算とコンバージェンスは、エントリがFIBにダウンロードされる前に行われる。

測定単位: N.A.

問題点:

関連項目: 経路、RIB

3.6. BGPインスタンス

定義: BGPインスタンスは1つのLoc-RIBを持つプロセスである。

考察: 例えば、BGPインスタンスはルータやテスト装置で実行される。複数のピアとして動作するテスト・ジェネレータは通常、複数のBGPインスタンスを実行する。通常、ルータは1つのインスタンスを実行する。

測定単位: N.A.

問題点:

関連項目:

3.7. BGPデバイス

定義: BGPデバイスとは、その上で1つ以上のBGPインスタンスが動作しているシステムのことで、それぞれのインスタンスがBGPステート・マシンの実行を担当する。

考察: 私たちは、制御処理がパケット転送と独立して行われている[RFC2918]ことを理解しており(例:[GLSSRY])、まだ発明されていないケースに対処するために、一般的なケースとして「デバイス」を使用することを選択した。BGPデバイスは、従来のルータ、経路サーバ、BGP対応トラフィック・ステアリング・デバイス、または非・フォワーディング・ルート・リフレクタである。例えば、ルート・リフレクタやサーバなどのBGPインスタンスは、トラフィックを転送しないため、フォワーディング・ベースの測定は意味がない。

測定単位: N.A.

問題点:

関連項目:

3.8. BGPセッション

定義: BGPセッションは、2つのBGPインスタンス間のセッションである。

考察:

測定単位: N.A.

問題点:

関連項目:

3.9. アクティブなBGPセッション

定義: アクティブなBGPセッションは、Established状態にあるセッションのことである。(RFC 1771を参照のこと。)

考察:

測定単位: N.A.

問題点:

関連項目:

3.10. BGPピア

定義: BGPピアは、DUTがEstablished状態にあるもう1つのBGPインスタンスである。(RFC 1771を参照のこと。)

考察: 本文書の後に続く方法論検討のためのテスト・シナリオにおいて、ピアはDUTにBGP広告を送信し、DUTから発信された広告を受信する。テスト開始前にピアリング関係を確立することを推奨する。確立された状態に到達するまでに必要な時間を測定することも面白いかもしれない。これはプロトコル固有の定義であり、金銭的な補償なしに経路を交換するビジネス/経済的な定義を指す、別のよくある用法と混同してはならない。この定義によれば、BGPピアはBGPピアリング・セッションに関連付けられ、ルータまたはテスター上にそのようなアクティブなセッションが複数存在する可能性があることに留意する。ここで言及されているピアリング・セッションは、さまざまなクラスのBGPルータ間に存在する可能性がある(セクション4.2参照)。

測定単位: BGPピア数

問題点:

関連項目:

3.11. BGPネイバー

定義: BGPネイバーは、BGPピアとして設定できるデバイスのことである。

考察:

測定単位:

問題点:

関連項目:

3.12. Minimum Route Advertising Interval (MRAI)

定義: (RFC 1771からの言い換え)MRAIタイマーは、1つのBGPデバイスから特定の宛先(プレフィックス)への経路を広告する間の最小時間を決定する。タイマーはプレプレフィックス単位で適用される。しかしながら、タイマーはBGPデバイスごとに設定する。

考察: BGPインスタンスが100,000を超える経路を管理する可能性があることを考えると、RFC 1771は必要なタイマーの数を制限するため、ある程度の最適化が許される。MRAIは、同じAS内のBGPスピーカーから受信した経路や明示的な撤回には適用されない。RFC 1771では、ネットワーク内のBGPインスタンス間の同期の影響を回避するため、ランダム・ジッターをMRAIに適用することを推奨している。本文書では、NLRIがDUTに広告された時点から、DUTから広告された時点までを測定することで、ルーティング・プレーンのコンバージェンスを定義する。明らかに、MRAIによって挿入される遅延は、この測定に大きな影響を与える。

測定単位: 秒

問題点:

関連項目: NLRI、BGP経路

3.13. Minimum AS Origination Interval (MAOI)

定義: MAOIは、このBGPインスタンスからのローカル発信された経路の広告の最小間隔を指定する。

考察: ランダム・ジッターは、ネットワーク内のBGPインスタンス間の同期効果を回避するためにMAOIに適用される。

測定単位: 秒

問題点: MRAIとMAOIの設定の間にどのような関係があるのかは不明である。

関連項目: MRAI、BGP経路

3.14. アクティブな経路

定義: RIBエントリに対応するFIBエントリが存在する経路。

考察:

測定単位: 経路数

問題点:

関連項目: RIB

3.15. ユニークな経路

定義: ユニークな経路は、すべてのAdj-RIB-Inに1つだけ経路インスタンスが存在するプレフィックスである。

考察:

測定単位: N.A.

問題点:

関連項目: 経路、経路インスタンス

3.16 ユニークではない(Non-Unique)経路

定義: ユニークではない経路とは、複数のAdj-RIB-Inを含むセットの中に少なくとも1つの他の経路が存在するプレフィックスである。

考察:

測定単位: N.A.

問題点:

関連項目: 経路、経路インスタンス、ユニークなアクティブな経路

3.17. 経路インスタンス

定義: 経路インスタンスは、特定のプレフィックスに対して考えられる(possible occurrences)経路の1つである。

考察: ルータが経路を受け入れる複数のピアを持つ場合、同じプレフィックスへの経路を複数のピアから受信する可能性がある。これが複数の経路インスタンスの例である。各経路インスタンスは特定のピアに関連付けられている。利用可能な経路インスタンス候補の間を調停(arbitrates)するBGPアルゴリズムは、ローカル・ポリシーにより特定の経路インスタンスを拒否することがある。

測定単位: 経路インスタンスの数

問題点: Adj-RIB-Inベースの経路インスタンスの数は、ルータが実行する機能に応じて異なる。デフォルト・フリー・ゾーン(セクション4.1.4参照)にあるプロバイダ間のボーダー・ルータは、ネットワークのエンドユーザに近いプロバイダ・エッジ・ルータよりも多くの経路インスタンスを受信する可能性がある。

関連項目:

4. ルータまたはルータのネットワークの構成要素

この定義リストに含まれる多くの用語は、元々は以前の規格または論文に記載されていたものである。これらは、この議論に適切(pertinence)であるため、ここに含まれている。関連する場合、これらの情報源を参照する。このリストは必要な概念に関して、過剰な定義を行わず、完全な状態に保つよう努めた。

4.1. デフォルト経路、デフォルトフリー・テーブル、フル・テーブル

個々のルータのルーティング・テーブルには、必ずしもデフォルト経路が含まれているとは限らない。しかし、デフォルト経路を持たないことは、完全なデフォルトフリー・テーブル(DFT)を持つことと同義ではない。また、DFTのようにフルセットの経路を持つルータでも、デフォルト経路の「破棄」(discard)ルールを持つルータは、デフォルトフリーとはみなされない。

このセクションで経路数への言及は、loc-RIBにインストールされている経路を指し、経路インスタンスではなくユニークな経路であることに留意する。また、経路インスタンスの総数は経路数の4～10倍になる可能性があることに留意する。

4.1.1. デフォルト経路

定義: デフォルト経路は、どんな宛先アドレスとも一致する。ルータが特定のパケットの宛先アドレスに対してMore Specificな経路を持っていない場合、ルータのフォワーディング・テーブル(フォワーディング情報ベース、つまりFIB)にそのエントリが含まれていれば、このパケットをデフォルト経路エントリのネクストホップに転送する。IPv4のデフォルト経路の表記は0.0.0.0/0、IPv6のデフォルト経路は0:0:0:0:0:0:0:0または::/0である。

考察:

測定単位: N.A.

問題点:

関連項目: デフォルトフリー・ルーティング・テーブル、経路、経路インスタンス

4.1.2. デフォルトフリー・ルーティング・テーブル

定義: デフォルトフリー・ルーティング・テーブルはデフォルト経路がなく、通常はネットワークのコアまたは最上位層のルータに見られる。

考察: この用語は、インターネットのコアまたは最上位層にあるルータは、デフォルト経路(IPv4の表記0.0.0.0/0、IPv6の表記0:0:0:0:0:0:0:0または::/0)が設定されていないという概念に由来する。そのため、宛先IPアドレスとフォワーディング・テーブル内の経路が最長一致に基づいて、すべてのパケットを特定のネクストホップに転送する。

デフォルトフリー・ルーティング・テーブルのサイズは、到達可能なインターネット・アドレス空間の大きさを示す指標として一般的に使われる。しかし、デフォルトフリー・ルーティング・テーブルには、ルータのAS内部の経路も含まれることがある。

測定単位: 経路数

関連項目: フル・デフォルトフリー・テーブル、デフォルト経路

4.1.3. フル・デフォルトフリー・テーブル

定義: フル・デフォルトフリー・テーブルは、パブリック・インターネットを構成する自律システムのフル・セットによってまとめてアナウンスされたデフォルトフリーのすべててのBGPルーティング・テーブルから取得したBGP経路の全集合を結合したものである。インターネットの動的な性質により、このテーブルの正確なサイズと構成(composition)は、観測する場所と時間によって若干異なることがある。

考察: この用法におけるフル・テーブルには、他の自律システムにアナウンスする前にプロバイダによって集約されるインフラの経路や経路の個々の部分集約(sub-aggregates)は含まれないことが一般に認められている。

測定単位: 経路数

問題点: フル・デフォルトフリー・ルーティング・テーブルは、到達可能なすべてのユニキャスト・アドレスを結合したものと同じではない。このテーブルにはデフォルト・プレフィックス(0/0)が含まれていないだけで、デフォルトフリーのBGPルーティング・テーブルからのBGP経路の全集合を結合したものが含まれているだけである。

関連項目: 経路、経路インスタンス、デフォルト経路

4.1.4. デフォルトフリー・ゾーン

定義: デフォルトフリー・ゾーンは、デフォルト経路を持たないインターネット・バックボーンの一部である。

考察:

測定単位:

問題点:

関連項目: デフォルト経路

4.1.5. フル・プロバイダ内部のテーブル

定義: フル・プロバイダ内部のテーブルは、インフラと非・集約経路を含むフル・ルーティング・テーブルのスーパーセットである。

考察: 経験上、このテーブルには外部から見えるフル・テーブルの1.3～1.5倍の経路数が含まれている可能性があることが分かっている。したがって、このサイズのテーブルが、主要な内部のプロバイダ・ルータにとって現実的な要件である。

測定単位: 経路数

問題点:

関連項目: 経路、経路インスタンス、デフォルト経路

4.2. BGPスピーキング・ルータのクラス

あるルータは、ネットワーク内の論理的な位置に基づいて、以下の機能のうち複数を実行する可能性がある。

4.2.1. プロバイダ・エッジ・ルータ

定義: プロバイダ・エッジ・ルータは、別のASのBGPスピーカーとeBGPを話すプロバイダのネットワークのエッジにあるルータである。

考察: このルータを通過するトラフィックは、隣接しない自律システムを宛先とする場合もあれば、そこから発信される場合もある。特に、プロバイダ・エッジ・ルータで使用されるMED値は、隣接しない自律システムには見えない。このようなルータは常にeBGPを話し、iBGPを話すこともある。

測定単位:

問題点:

関連項目:

4.2.2. 加入者エッジ・ルータ

定義: 加入者エッジ・ルータは、プロバイダのASにeBGPを話す加入者ネットワークのエッジにあるルータである。

考察: このルータは、マルチホームの可能性があるエンド・ユーザ組織に属しており、エンド・ユーザのASとの間でのみトラフィックを伝送する。このようなルータは常にeBGPを話すが、iBGPを話すこともある。

測定単位:

問題点: 企業ボーダー・ルータ(ほとんどの加入者エッジ・ルータがこれに該当する)の定義は、厳密ではなく実用的なものである。これは、多くの企業が独自の経路を広告し、デフォルトのみまたは部分的な経路を受け入れるBGPスピーカーを必要とする可能性があるという現実に注意を喚起することを目的としている。このような場合、より小規模のコントロール・プレーンのプロセッサがニーズを満たせるかどうかを確認するために、部分的なルーティング・テーブルを使用したベンチマークに興味を持つかもしれない。

関連項目:

4.2.3. プロバイダ間ボーダー・ルータ

定義: プロバイダ間ボーダー・ルータは、他のプロバイダのASにある他のBGPスピーキング・ルータとのBGPセッションを維持するBGPスピーキング・ルータである。

考察: このルータを通過するトラフィックは、このプロバイダのASと直接接続していない別のASで発信(originated)、または向けられる(destined)可能性がある。このようなルータは常にeBGPを話すが、iBGPを話すこともある。

測定単位:

問題点:

関連項目:

4.2.4. コア・ルータ

定義: コア・ルータは、プロバイダのネット内部のプロバイダ・ルータであり、そのプロバイダのエッジ・ルータ、他のプロバイダ内コア・ルータ、またはプロバイダのプロバイダ間ボーダー・ルータとiBGPを話す。

考察: このようなルータは常にiBGPを話すが、eBGPを話すこともある。

測定単位:

問題点: この定義によれば、eBGPルータであるDUTはコア・ルータではない。

関連項目:

5. 一連のアップデート・メッセージの特徴

このセクションは、アップデート・トレインの定義を補強する(build up)一連の定義を含む。パケット・トレインの概念は、もともとジェーンとルーティエによって導入された[PKTTRAIN]。ここでは、BGP性能テストで注目されるパケット・トレインを指すように適応されている。

これは、BGPを実行するDUTへの入力として期待されるある種のテスト刺激(test stimulus)を形式化したものである。このデータは、よく特徴付けられ、順序付けされ、時間指定された、手作りのBGP UPDATEパケット・セットである可能性がある。ライブのルータからキャプチャされたBGP UPDATEパケットのセットである可能性もある。

経路ミックスとアップデート・トレインの特性評価は、未解決の研究分野である。この研究で特に興味深いのは、現実的なUPDATEのシーケンスとその内容を反映した、ライブ・トレースに基づいてモデル化された、あるいはライブ・トレースから取得した、適切なアップデート・トレインを特定することである。

5.1. 経路パッキング

定義: 経路パッキングとは、1つのルーティング・プロトコルのUPDATEメッセージに収容される経路プレフィックスの数で、アップデート(追加または変更)または撤回のいずれかである。

考察: 一般に、ルーティング・プロトコルのアップデートは複数のプレフィックスが含まれることがある。BGPでは、1つのUPDATEに複数のネットワーク・プレフィックスが2セット含まれることがある。1つは同一の属性(NLRI)を持つ追加と更新のセット、もう1つは撤回される実行不可能(unfeasible)な経路のセットである。

測定単位: プレフィックスの数。

問題点:

関連項目: 経路、BGP経路、経路インスタンス、アップデート・トレイン、NLRI

5.2. 経路ミックス

定義: 経路ミックスとは、一連の経路のデモグラフィックである。

考察: 経路ミックスはベンチマークの入力データである。入力として使用される特定の経路ミックスは、ベンチマークで問われる問題に合わせて選択する必要がある。BGPデバイスの性能限界をテストするには、単純な経路ミックスを含むデータが適しているかもしれない。ライブ・データまたはライブ・データをシミュレートする入力を使用すると、BGPデバイスがライブ・ネットワークでどのように動作するかの理解が深まる。この種のテスト・データは、ライブ・インターネットにおけるコントロール・トラフィックのパターンをモデル化した経路ミックスでなければならない。この種のモデル化を達成するためには、ライブ・インターネットの経路ミックスを特徴付ける主要なパラメータを特定する必要がある。パラメータとそれらがどのように相互作用するかは、未解決の研究課題である。しかし、経路ミックスに影響を与えるものとして、以下のことが確認されている。

経路長分布
属性分布
プレフィックス長の分布
パケット・パッキング
UPDATEの到着間隔の確率密度関数

上記の各項目は、1つの数値よりも複雑である。例えば、AS別や長さ別のプレフィックスの分布を考えることができる。

測定単位: 確率密度関数

問題点:

関連項目: NLRI、RIB

5.3. アップデート・トレイン

定義: アップデート・トレインは、ルータがBGPピアに送信する一連のルーティング・プロトコルのUPDATEメッセージである。

考察: UPDATEの到着パターンは、TCPパラメータ、ホールドダウン・タイマー、アップストリーム処理、ピアの起動、または複数のピアが同時に送信するなど、さまざまな要因によって影響を受ける可能性がある。ローカルまたはリモートのピアがリンクをフラッピングさせるなどのネットワーク状態も、到着パターンに影響を与える可能性がある。

測定単位: トレイン内のUPDATEパケットの到着間隔の確率密度関数

問題点: 実世界のUPDATEトレインのプロファイルを特徴付けることは、今後の研究課題である。テスト刺激として現実的なUPDATEトレインを生成するには、プレフィックスの選択を行うための正式な数学的スキーム、または実証済みのヒューリスティックが必要である。どのようなメカニズムが選択するにせよ、ライブ・ネットワークで測定されたものと同様の特性を持つアップデート・トレインを生成しなければならない。

関連項目: 経路ミックス、MRAI、MAOI

5.4. アップデート・トレインのランダム性

前のセクションで見てきたように、テスト刺激として使用されるアップデート・トレインには、多かれ少なかれ、ランダムかつ独立して変化させることができるかなりの数のパラメータを持っている。

ランダムなアップデート・トレインは、以下の間でランダムにミックスされた経路が含まれる:

NLRI
アップデートと撤回(withdrawals)
プレフィックス
UPDATEと場合によっては他の変数間の到着間隔時間

これは、ネットワークの予測不可能な非同期の性質をシミュレートすることを目的としており、UPDATEパケットは任意の内容を持ち、ランダムな時間に配信される可能性がある。

あるベンダーの実装が別のベンダーの実装よりも優先されることを避けるため、データセットを十分にランダム化することが重要である。具体的には、プレフィックスの分布は、特定のベンダーのデータベースの経路の内部構成に有利になるように構造化される可能性がある。これは避けなければならない。

5.5. 経路フラップ

定義: 経路フラップは、経路の状態変化(撤回、アナウンス、属性変更)のことである。

考察: 経路のバタつき、アップデート・トレインの特殊かつ病的なケースと考えることができる。何が過度に速いと考えられるかについての実際的な解釈は、フラップ減衰パラメータに関する現在のガイドラインを含むRIPE 229[RIPE229]である。

測定単位: 単位時間あたりのフラッピング(バタつき)

問題点: 特定のフラップ・イベントはセクション6.1に記載している。ベンチマーカーは、テストでさまざまな経路変更イベントをミックスして使用する必要がある(SHOULD)。

関連項目: 経路変化イベント、フラップ・ダンピング、パケット・トレイン

6. 経路変化とコンバージェンス

次の2つの定義は、外部ルーティングのコンバージェンスのベンチマークにとって中心となるため、より広範な議論のために取り上げる。

6.1. 経路変化イベント

RIPE-37[RIPE37]やラボヴィッツらの[INSTBLTY]において、運用ネットワークで見られるルーティング情報の変化を特徴付ける分類法が提案されている。これらの文書では、ネットワークの動作分析過程でBGPプロトコル中心のイベントとイベント・シーケンスを説明している。2つの論文の用語は、類似しているが若干異なる動作をいくつかの重複部分を含めて分類している。これらのテストは実際のネットワークで発生する現象と関連付けなければならないため、可能な限り、これらの分類を適用した定義に基づいて、テストを分類したいと考えている。この目的のために必要であれば、この用語集を利用し、あるいは拡張することもある。

経路は、別の経路と置き換えることで暗黙的に変更されることもあれば、撤回後に新しい経路を導入することで明示的に変更されることもある。いずれの場合も、変化は実際の変更である場合もあれば、変更がない場合もあれば、その重複である場合もある。個々の分類可能な経路変化イベントの表記と定義は、[INSTBLTY]から採用され、以下に示す。

AADiff: 経路を暗黙的に撤回、あるパス属性が異なる経路に置き換える。
AADup: 経路を暗黙的に撤回、すべてのパス属性が同一の経路に置き換える。
WADiff: 明示的に経路を撤回、別の経路に置き換える。
WADup: 経路を明示的に撤回、すべてのパス属性が同一の経路に置き換える。

この分類法をベンチマークの文脈に適用するには、上記のように、アップデート・トレインの観点からイベントのシーケンスを記述するための用語と、DUTの観点からアクティビティを測定するための時間領域でのイベント指示(event indications)が必要である。これを念頭に置いて、[INSTBLTY]の定義を以下のように組み込み、拡張する:

Tup(TDx): テストデバイスxによってDUTに広告される経路
Tdown(TDx): デバイスxによって撤回される経路
Tupinit(TDx): ユニークなプレフィックスへの経路の最初のアナウンス
TWF(TDx): 明示的な撤回後の経路フェイルオーバー

しかし、私たちはこれをさらに一歩進める必要がある。これらの各イベントは、1つの経路、「短い」パケット・トレイン、または「フル」ルーティング・テーブルを含めることができる。表記法をさらに拡張して、上記イベントによっていくつの経路が伝達されるかを示す:

Tup(1,TDx)は、デバイスxが1つの経路を送信することを意味する。
Tup(S,TDx)は、デバイスxが経路Sトレインを送信することを意味する。
Tup(DFT,TDx)は、デバイスxがフル・デフォルトフリー・テーブルの近似を送信することを意味する。

「より良い」経路を選択するための基本的な基準は、RFC 1771で定義されている最終的なタイブレーカーであるルータIDである。結果として、この覚書では、単純なアップデートではなく、BGP選択プロセスによって選択された経路である、以下の記述子イベントを使用する。

Tbest -- 現在の最適パス。
Tbetter -- Tbestよりも良いパスを広告する。
Tworse -- Tbestよりも悪いパスを広告する。

6.2. コントロール・プレーンにおけるデバイスのコンバージェンス

定義: ルーティング・デバイスは、DUTがテスト条件の文脈でトポロジの変化に反応するために必要なコントロール・プレーンのすべてのアクションを実行した時点で収束したと言う。

考察: 例えば、BGPのコンバージェンスを考えるとき、あるルータでの1つプレフィックスの最適な経路インスタンスが変更された場合、その経路がダウンストリーム・ピアに広告された時点でコンバージェンスが完了したとみなされる。対照的に、OSPFのコンバージェンスは、SPF計算が実行され、必要なリンク状態が先方に広告された時点で完了する。一般的に、コンバージェンスのプロセスは、以下の3つのフェーズに分けられる。

インターネット全体のコンバージェンス
自律システム内でのコンバージェンス
単一のデバイスに関するコンバージェンス

単一のデバイスに関するコンバージェンスは、

データのフォワーディング・プロセスに関するコンバージェンス
ルーティング・プロセスに関するコンバージェンスで、本文書の焦点

仕様および方法論の文書で説明するのは後者である。私たちはルーティング・プロトコルの性能をベンチマークしようとしているが、それはデバイス全体の一部でしかないため、この定義はデータ・プレーンのフォワーディング情報ベースのダウンロードとインストールに必要な追加時間を(可能な限り)排除することを目的としている。この定義はさまざまなプロトコル・ファミリーに使用できる。

実装固有の依存関係が相互作用するルーティングのコンバージェンスの複合的な特性評価に進む前に、コンバージェンスの各フェーズの性能を個別にベンチマークすることが非常に重要である。また、コンバージェンス時間がダウンストリーム・ピアのポリシー処理に影響されないように注意する必要がある。デバイスのコンバージェンスを測定するために必要な時間分解能は、ルータ上のインタフェースの種類にある程度依存する。ギガビット以上のインタフェースを備えた最新のルータの場合、個々のUPDATEは1ミリ秒未満で処理され、再広告されるため、時間測定は数百から数十マイクロ秒以上の分解能で行う必要がある。

測定単位: 期間

問題点:

関連項目:

7. BGPのオペレーション・イベント

オペレータの介入や障害によって完全に停止が発生したため、デバイスのBGPプロセスが再起動する場合がある。この場合、ハードリセットが必要である。ピアリング・セッションは、例えば、ピア側の操作やTCPセッションの停止などにより、失われる可能性がある。デバイスはハードリセットで、ピアを再確立し、関連するすべての経路を再広告できる。ただし、ピアが失われても、BGPプロセスが落ちない場合、BGPには「ソフトリセット」のメカニズムがある。

7.1. ハードリセット

定義: 1つ以上のBGPセッションのルーティング・テーブルの完全な再初期化をトリガーするイベントで、その結果、ルータへの1つ以上のリンクで完全なルーティング・テーブルが交換される。

考察:

測定単位: N.A.

問題点:

関連項目:

7.2. ソフトリセット

定義: ソフトリセットはネイバーごとに実行される。そして、ピアリング関係を再確立する間、BGPセッションはクリアされず、トラフィック・フローも停止しない。

考察: ソフトリセットを実行するには2つの方法がある。(1) グレースフル・リスタート[GRMBGP]、ピアを失ったBGPデバイスがピアの経路を破棄する前に一定期間トラフィックを転送し続ける。(2) ソフト・リフレッシュ[RFC2918]、BGPデバイスがピアのAdj-RIB-Outを要求できる。

測定単位: N.A.

問題点:

関連項目:

8. コンバージェンス・プロセスの性能に影響を与える要因

これは完全なリストではないが、以下に説明するすべての項目がBGPコンバージェンスに大きな影響を与える。本文書で説明するベースライン測定では、そのすべてに対処できるわけではない。

8.1. デバイスのコンバージェンスに影響を与える一般的な要因

これらの要因は、ルータのテスト対象デバイス(DUT)の外部におけるテスト条件である。

8.1.1. ピア数

ピア数が増えるにつれて、BGP経路選択アルゴリズムはさらに負荷がかかる(exercised)。さらに、さまざまなピアからのアップデートの局面と頻度も、ピア数が増えるにつれて、追加の各ピアによって生成されるアップデートの量に応じて、ルータのコンバージェンス・プロセスにますます大きな影響を与えるようになる。ピア数が増えると、TCPとBGPのキープアライブの処理負荷も増加する。

8.1.2. ピアあたりの経路数

BGPピアあたりの経路数は、コンバージェンス・プロセスにとって明らかなストレス要因である。各ピアによって追加または撤回される複数の経路インスタンスと異なる経路数と相対的な割合は、重複する経路インスタンスとIGP経路の組み合わせと同様に、コンバージェンス・プロセスに影響する。

8.1.3. ポリシーの処理/再設定

フィルタリングされ、そしてターゲット経路テーブル・サイズに対する割合として設定される経路と属性数は、BGPコンバージェンスに影響を与えるもう1つのパラメータである。

以下は極端な例である:

最小ポリシー: すべてを受信し、すべてを送信する。
広範なポリシー: 全経路の100%まで適用可能なポリシーがある。

8.1.4. 他のプロトコルとの相互作用

優先順位、同期、重複、タイマーや経路選択基準の追加といった形での相互作用がある。最終的に、BGP4コンバージェンスを理解するには、IGPとイーサネット、SONET、DWDMなどの物理メディアに関連付けられたプロトコルの両方との対話を理解する必要がある。

8.1.5. フラップ・ダンピング

ルータは経路のバタつきに対応するためにフラップ・ダンピングを使うことができる。フラップ・ダンピングの使用は必須ではないため、この機能を有効にするかどうか、またそれに関連するパラメータを変更するかどうかは、ルーティング・ポリシーの問題と考えることができる。

タイマーはRFC 2439[RFC2439]で定義され、RIPE-229[RIPE229]で議論されている。この機能が有効な場合、デバイスがダンピングを実行するために追加の状態を保持する必要があり、処理の増加によってコントロール・プレーンに直接的な影響を与える可能性がある。さらに、フラップ・ダンピングは経路の実際の変更の到着が遅らせ、コンバージェンス時間に影響を与える可能性がある。

8.1.6. チャーン(Churn)

理論的には、BGPデバイスはインターネットを完全に定義する一連のUPDATEを受信することができ、適切なキープアライブを送信するだけで定常状態を保つことができる。実際には、インターネットは常に変化している。

チャーンとは、ルータが送受信されるアナウンスによって引き起こされるコントロール・プレーン・プロセッサの動き(activity)を指す。キープアライブやTCP処理は含まない。

チャーンは、正常なイベントと異常なイベントの両方によって引き起こされる。例えば、ローカル・ルータのインタフェースがダウンし、関連するプレフィックスが撤回された場合、その撤回はチャーンの原因となるが、通常なアクティビティである。ローカル・デバイスが、既に広告している経路の撤回や、以前は知らなかった経路のアナウンスを受信し、この情報を再広告する場合、これらはチャーンの通常の構成要素である。定期的なアップデートは、1つのアナウンスや撤回から、デフォルトフリー・テーブル全体のアナウンスまで多岐にわたる。後者は初期化条件として完全に妥当である。

経路のバタつきは、MEDオシレーション(振動) [RFC3345]と同様に、チャーンの異常要因となる。フラップ・ダンピングの目的は、チャーンに対するバタつきの寄与を軽減することである。

チャーンが全体的なコンバージェンスに及ぼす影響は、コントロール・プレーンに利用可能な処理能力と、フォワーディングとコントロールに同じプロセッサが使用されているかどうかに依存する。

8.2. BGPコンバージェンスに影響を及ぼす実装固有の要因およびその他の要因

これらの要因は、テスト対象デバイス(DUT)内部のテスト条件だが、テスト・デバイスとの相互作用に影響を与える可能性がある。

8.2.1. 転送されたトラフィック

デバイス内に実際のトラフィックが存在する場合、提供される負荷(データによる)とコントロール・トラフィック(バタつきの結果としてのFIBアップデートとダウンロード)の両方が過剰であれば、何らかの形でコントロール・パスにストレスを与える可能性がある。データ・トラフィックを追加すると、コントロール・トラフィックのみが存在する場合よりも、現実的な運用シナリオがより正確に反映する。

8.2.2. タイマー

BGP4と同様、リンクレベルでの遅延タイマーとホールドダウン・タイマーの設定は、遅延を発生させたり、改善したりする可能性がある。テストレポートの一部として、関連するタイマーがデフォルト値以外を使用する場合はすべて報告しなければならない(MUST)。

8.2.3. BGPトランスポートの基礎となるTCPパラメータ

すべてのBGPトラフィックとやり取りはTCP上で発生するため、TCPセッションを特徴付けるすべての関連パラメータを提供しなければならない(MUST)。例えば、スロースタート、最大ウィンドウ・サイズ、最大セグメント・サイズ、タイマーなどである。

8.2.4. 認証

BGPの認証は現在、TCP MD5署名オプション[RFC2385]を使用して行われる。MD5ハッシュの処理は、特に多数のBGPピアと大量のアップデート・トラフィックを持つデバイスでは、デバイスのコントロール・プレーンに影響を与える可能性がある。

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

本文書は、性能に影響を与える機能として、認証を明確に考慮しているが、ルーティング・システム全体のセキュリティは考慮していない。

10. 謝辞

レビューをしてくれたフランシス・オベンデンと激励してくれたアバ・アフジャに感謝する。Nexthopのジェフ・ハース、マット・リチャードソン、シェーン・ライトのコメント意見に感謝する。デビー・ストップとニック・アンブローズは、経路パッキングのコンセプトに貢献してくれた。

アルバロ・レタナは、本文書を作成したチームの主要メンバーであり、経路ミックスに関して多大な技術的貢献をした。チームは彼に感謝し、彼を精神的な共著者とみなしている。

11. 参考文献

11.1. 引用規格

[RFC1771] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, March 1995.

[RFC2439] Villamizar, C., Chandra, R., and R. Govindan, "BGP Route Flap Damping", RFC 2439, November 1998.

[RFC1812] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, June 1995.

[RIPE37] Ahuja, A., Jahanian, F., Bose, A., and C. Labovitz, "An Experimental Study of Delayed Internet Routing Convergence", RIPE-37 Presentation to Routing WG, November 2000, <http://www.ripe.net/ripe/meetings/archive/ripe-37/presentations/RIPE-37-convergence/>

[INSTBLTY] Labovitz, C., Malan, G., and F. Jahanian, "Origins of Internet Routing Instability", Infocom 99, August 1999.

[RFC2622] Alaettinoglu, C., Bates, T., Gerich, E., Karrenberg, D., Meyer, D., Terpstra, M., and C. Villamizar, "Routing Policy Specification Language (RPSL)", RFC 2280, January 1998.

[RIPE229] Panigl, C., Schmitz, J., Smith, P., and C. Vistoli, "RIPE Routing-WG Recommendation for coordinated route-flap damping parameters, version 2", RIPE 229, October 2001.

[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, August 1998.

[GLSSRY] Juniper Networks, "Junos(tm) Internet Software Configuration Guide Routing and Routing Protocols, Release 4.2", Junos 4.2 and other releases, September 2000, <http://www.juniper.net/techpubs/software/junos/junos42/swcmdref42/html/glossary.html>

.[RFC2547] Rosen, E. and Y. Rekhter, "BGP/MPLS VPNs", RFC 2547, March 1999.

[PKTTRAIN] Jain, R. and S. Routhier, "Packet trains -- measurement and a new model for computer network traffic", IEEE Journal on Selected Areas in Communication 4(6), September 1986.

11.2. 参考規格

[RFC2918] Chen, E., "Route Refresh Capability for BGP-4", RFC 2918, September 2000.

[GRMBGP] Sangli, S., Rekhter, Y., Fernando, R., Scudder, J., and E. Chen, "Graceful Restart Mechanism for BGP", Work in Progress, June 2004.

[BGP-4] Chen, E. and Y. Rekhter, "Cooperative Route Filtering Capability for BGP-4", Work in Progress, March 2004.

[RFC3654] Khosravi, H. and T. Anderson, "Requirements for Separation of IP Control and Forwarding", RFC 3654, November 2003.

[RFC3345] McPherson, D., Gill, V., Walton, D., and A. Retana, "Border Gateway Protocol (BGP) Persistent Route Oscillation Condition", RFC 3345, August 2002.

[RFC2858] Bates, T., Rekhter, Y., Chandra, R., and D. Katz, "Multiprotocol Extensions for BGP-4", RFC 2858, June 2000.

[RFC2545] Marques, P. and F. Dupont, "Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing", RFC 2545, March 1999.

著者のアドレス

ハワード・バーコウィッツ
Gett Communications & CCI Training
5012 S. 25th St
Arlington, VA 22206
アメリカ合衆国
電話: +1 703 998-5819
ファックス: +1 703 998-5058
メール: hcb@gettcomm.com

エルウィン・B・デイヴィス
Folly Consulting
The Folly
Soham
Cambs, CB7 5AW
イギリス
電話: +44 7889 488 335
電子メール: elwynd@dial.pipex.com

スーザン・ヘアズ
Nexthop Technologies
825 Victors Way
Ann Arbor, MI 48108
アメリカ合衆国
電話: +1 734 222-1610
メール: skh@nexthop.com

パドマ・クリシュナスワミ
SAIC
331 Newman Springs Road
Red Bank, New Jersey 07701
アメリカ合衆国
メール:padma.krishnaswamy@saic.com

マリアンヌ・レップ
コンサルタント
メール: mlepp@lepp.com

完全な著作権に関する声明

著作権 (C) The Internet Society (2005)。

本文書は、BCP 78に含まれる権利、ライセンス、制限に従うものであり、そこに規定されている場合を除き、著者はすべての権利を保持する。

本文書およびここに含まれる情報は「現状のまま」で提供されるものであり、寄稿者、寄稿者が代表または後援する組織(存在する場合)、インターネット協会およびインターネット・エンジニアリング・タスク・フォースは、すべての保証を否認する。これは、明示または黙示を問わず、ここに記載された情報の使用がいかなる権利も侵害しないという保証、または商品性や特定の目的への適合性の黙示的な保証を含むが、これに限定されない。

知的財産

IETFは、本文書に記載されたテクノロジーの実装または使用に関連すると主張されうる知的財産権またはその他の権利の有効性や範囲、あるいはそのような権利に基づくライセンスがどの程度利用可能か不可能かに関して、いかなる立場も取らない。利用可能であること。また、そのような権利を特定するために独自の努力を行ったことを表明するものでもない。RFC文書の権利に関する手続きに関する情報は、BCP 78およびBCP 79に記載されている。

IETF事務局に対して行われたIPR開示の写し、および利用可能になるライセンスの保証、または本仕様の実装者や利用者がそのような保有権の使用するための一般ライセンスや許可を取得しようとする試みの結果は、IETFのオンラインIPRリポジトリ(http://www.ietf.org/ipr) から入手できる。

IETFは、本規格の実装に必要とされる技術をカバーする著作権、特許、特許出願、その他の保有権について、利害関係者に対して注意を喚起するよう求める。情報はIETF(ietf-ipr@ietf.org)に送っていただきたい。

謝辞

RFCエディター機能の資金は現在、インターネットソサエティから提供されている。

更新履歴

2024.3.20

GitHubで編集を提案