Network Working Group H. Berkowitz
Request for Comments: 4098 Gett Communications & CCI Training
Category: Informational E. Davies, Ed.
Folly Consulting
S. Hares
Nexthop Technologies
P. Krishnaswamy
SAIC
M. Lepp
Consultant
June 2005
Terminology for Benchmarking BGP Device Convergence
in the Control Plane
Status of This Memo
このメモのステータス
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（2005）。
Abstract
抽象
This document establishes terminology to standardize the description of benchmarking methodology for measuring eBGP convergence in the control plane of a single BGP device. Future documents will address iBGP convergence, the initiation of forwarding based on converged control plane information and multiple interacting BGP devices. This terminology is applicable to both IPv4 and IPv6. Illustrative examples of each version are included where relevant.
この文書は、単一のBGP装置の制御プレーン内のeBGPコンバージェンスを測定するためのベンチマーク方法論の記述を標準化するために用語を確立します。将来の文書は、iBGPの収束、収束した制御プレーン情報と複数の相互作用のBGPデバイスに基づいて転送の開始に対処します。この用語は、IPv4とIPv6の両方に適用可能です。各バージョンの実例は、該当する場合に含まれます。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Overview and Road Map ......................................4
1.2. Definition Format ..........................................5
2. Components and Characteristics of Routing Information ...........5
2.1. (Network) Prefix ...........................................5
2.2. Network Prefix Length ......................................6
2.3. Route ......................................................6
2.4. BGP Route ..................................................7
2.5. Network Level Reachability Information (NLRI) ..............7
2.6. BGP UPDATE Message .........................................8
3. Routing Data Structures and Route Categories ....................8
3.1. Routing Information Base (RIB) .............................8
3.1.1. Adj-RIB-In and Adj-RIB-Out ..........................8
3.1.2. Loc-RIB .............................................9
3.2. Prefix Filtering ...........................................9
3.3. Routing Policy ............................................10
3.4. Routing Policy Information Base ...........................10
3.5. Forwarding Information Base (FIB) .........................11
3.6. BGP Instance ..............................................12
3.7. BGP Device ................................................12
3.8. BGP Session ...............................................13
3.9. Active BGP Session ........................................13
3.10. BGP Peer .................................................13
3.11. BGP Neighbor .............................................14
3.12. MinRouteAdvertisementInterval (MRAI) .....................14
3.13. MinASOriginationInterval (MAOI) ..........................15
3.14. Active Route .............................................15
3.15. Unique Route .............................................15
3.16. Non-Unique Route .........................................16
3.17. Route Instance ...........................................16
4. Constituent Elements of a Router or Network of Routers .........17
4.1. Default Route, Default-Free Table, and Full Table .........17
4.1.1. Default Route ......................................17
4.1.2. Default-Free Routing Table .........................18
4.1.3. Full Default-Free Table ............................18
4.1.4. Default-Free Zone ..................................19
4.1.5. Full Provider-Internal Table .......................19
4.2. Classes of BGP-Speaking Routers ...........................19
4.2.1. Provider Edge Router ...............................20
4.2.2. Subscriber Edge Router .............................20
4.2.3. Inter-provider Border Router .......................21
4.2.4. Core Router ........................................21
5. Characterization of Sets of Update Messages ....................22
5.1. Route Packing .............................................22
5.2. Route Mixture .............................................23
5.3. Update Train ..............................................24
5.4. Randomness in Update Trains ...............................24
5.5. Route Flap ................................................25
6. Route Changes and Convergence ..................................25
6.1. Route Change Events .......................................25
6.2. Device Convergence in the Control Plane ...................27
7. BGP Operation Events ...........................................28
7.1. Hard Reset ................................................28
7.2. Soft Reset ................................................29
8. Factors That Impact the Performance of the Convergence
Process ........................................................29
8.1. General Factors Affecting Device Convergence ..............29
8.1.1. Number of Peers ....................................29
8.1.2. Number of Routes per Peer ..........................30
8.1.3. Policy Processing/Reconfiguration ..................30
8.1.4. Interactions with Other Protocols ..................30
8.1.5. Flap Damping .......................................30
8.1.6. Churn ..............................................31
8.2. Implementation-Specific and Other Factors Affecting BGP ...31
8.2.1. Forwarded Traffic ..................................31
8.2.2. Timers .............................................32
8.2.3. TCP Parameters Underlying BGP Transport ............32
8.2.4. Authentication .....................................32
9. Security Considerations ........................................32
10. Acknowledgements ..............................................32
11. References ....................................................33
11.1. Normative References ....................................33
11.2. Informative References ..................................34
This document defines terminology for use in characterizing the convergence performance of BGP processes in routers or other devices that instantiate BGP functionality. (See 'A Border Gateway Protocol 4 (BGP-4)' [RFC1771], referred to as RFC 1771 in the remainder of the document.) It is the first part of a two-document series, of which the subsequent document will contain the associated tests and methodology. This terminology is applicable to both IPv4 and IPv6. Illustrative examples of each version are included where relevant. However, this document is primarily targeted for BGP-4 in IPv4 networks. IPv6 will require the use of MP-BGP [RFC2858], as described in RFC 2545 [RFC2545], but this document will not address terminology or issues specific to these extensions of BGP-4. Also terminology and issues specific to the extensions of BGP that support VPNs as described in RFC 2547 [RFC2547] are out of scope for this document.
この文書では、ルータやBGP機能のインスタンスを他のデバイスにBGPプロセスの収束性能を特徴付ける際に使用するための用語を定義します。 （「ボーダーゲートウェイプロトコル4（BGP-4）」[RFC1771]を参照、文書の残りの部分にRFC 1771と称する。）これは、後続の文書に含まれる2つの文書シリーズの最初の部分であります関連するテストや方法論。この用語は、IPv4とIPv6の両方に適用可能です。各バージョンの実例は、該当する場合に含まれます。しかし、この文書は主にIPv4ネットワークにBGP-4を対象としています。 RFC 2545 [RFC2545]で説明したようにIPv6は、MP-BGP [RFC2858]の使用が必要になりますが、この文書では、BGP-4のこれらの拡張機能に特有の用語や問題を解決しません。また、専門用語およびRFC 2547 [RFC2547]で説明したようにVPNをサポートするBGPの拡張に固有の問題、このドキュメントの範囲外です。
The following observations underlie the approach adopted in this document, and in the companion document:
次の観察は、この文書では、コンパニオン文書に採用されたアプローチの根底：
o The principal objective is to derive methodologies that standardize conducting and reporting convergence-related measurements for BGP.
Oの主な目的は、導電性およびBGPの収束に関連する測定値を報告する標準方法を得ることです。
o It is necessary to remove ambiguity from many frequently used terms that arise in the context of these measurements.
Oこれらの測定の文脈において生じる多くの頻繁に使用される用語の曖昧さを除去する必要があります。
o As convergence characterization is a complex process, it is desirable to restrict the initial focus in this set of documents to specifying how to take basic control-plane measurements as a first step in characterizing BGP convergence.
収束の特性は複雑なプロセスであるようにO、BGPコンバージェンスを特徴付けるための最初のステップとして、基本的な制御プレーン測定を行う方法を指定する文書のセットの最初の焦点を制限することが望ましいです。
For path-vector protocols, such as BGP, the primary initial focus will therefore be on network and system control-plane [RFC3654] activity consisting of the arrival, processing, and propagation of routing information.
BGPなどのパスベクトルプロトコルのために、一次最初の焦点は、したがって、ネットワークとシステムコントロールプレーンに到着、処理、及びルーティング情報の伝搬からなる[RFC3654]活性であろう。
We note that for testing purposes, all optional parameters SHOULD be turned off. All variable parameters SHOULD be at their default setting unless the test specifies otherwise.
私たちは、テストの目的のために、すべてのオプションパラメータをオフにする必要があることに注意してください。テストに特別な指示がない限り、すべての変数のパラメータは、デフォルトの設定にする必要があります。
Subsequent documents will explore the more intricate aspects of convergence measurement, such as the impacts of the presence of Multiprotocol Extensions for BGP-4, policy processing, simultaneous traffic on the control and data paths within the Device Under Test (DUT), and other realistic performance modifiers. Convergence of Interior Gateway Protocols (IGPs) will also be considered in separate documents.
その後の文書は、そのようなテスト（DUT）中の装置内の制御及びデータパス上のBGP-4、ポリシー処理、同時トラフィックのマルチ拡張の存在の影響としてコンバージェンス測定のより複雑な側面を探索し、現実的であろう他のパフォーマンスの修飾子。インテリアゲートウェイプロトコル（IGPの）の収束はまた別の文書に考慮されます。
Characterizations of the BGP convergence performance of a device must-take into account all distinct stages and aspects of BGP. functionality. This requires that the relevant terms and metrics be as specifically defined as possible. Such definition is the goal of this document.
デバイスのBGPの収束性能の特徴付けを考慮にBGPのすべての異なる段階および側面を-取る必要があります。機能。これは、関連する用語やメトリックはできるだけ具体的に定義されている必要があります。このような定義は、この文書の目標です。
The necessary definitions are classified into separate categories:
必要な定義は、別のカテゴリに分類されます。
o Components and characteristics of routing information
Oコンポーネントとルーティング情報の特性
o Routing data structures and route categories
Oデータ構造とルートカテゴリをルーティング
o Descriptions of the constituent elements of a network or a router that is undergoing convergence
ネットワークの構成要素または収束を受けているルータのO説明
o Characterization of sets of update messages, types of route-change events, as well as some events specific to BGP operation
BGP操作に特定の更新メッセージ、ルート変更イベントのタイプ、ならびにいくつかのイベントの組のOキャラクタリゼーション
o Descriptions of factors that impact the performance of convergence processes
収束プロセスのパフォーマンスに影響を与える要因のO説明
The definition format is equivalent to that defined in 'Requirements for IP Version 4 Routers' [RFC1812], and is repeated here for convenience:
定義の形式は、「IPバージョン4つのルータのための要件」[RFC1812]で定義されたものに相当し、利便性のためにここで繰り返されます。
X.x Term to be defined (e.g., Latency).
X.x用語が定義される（例えば、レイテンシ）。
Definition: One or more sentences forming the body of the definition.
定義：定義の本体を形成する1つのまたは複数の文。
Discussion: A brief discussion of the term, its application, and any restrictions that there might be on measurement procedures.
ディスカッション：用語、その応用、及び測定手順上があるかもしれないと何の制限の簡単な説明。
Measurement units: The units used to report measurements of this term. This item may not be applicable (N.A.).
測定単位：本項の測定結果を報告するために使用される単位。こちらは（N.A.）適用可能でないかもしれません。
Issues: List of issues or conditions that could affect this term.
問題：この用語に影響を与える可能性がある問題や条件のリスト。
See also: List of related terms that are relevant to the definition or discussion of this term.
参照してください：この用語の定義や議論に関連している関連用語のリスト。
Definition: "A network prefix is a contiguous set of bits at the more significant end of the address that collectively designates the set of systems within a network; host numbers select among those systems." (This definition is taken directly from section 2.2.5.2, "Classless Inter Domain Routing (CIDR)", of RFC 1812.)
定義：「ネットワークプレフィックスをまとめてネットワーク内のシステムのセットを指定するアドレスの上位端部におけるビットの連続集合である、ホスト番号は、それらのシステム間で選択してください。」 （この定義は、セクション2.2.5.2から直接取得され、「クラスレスインタードメインルーティング（CIDR）」、RFC 1812の）
Discussion: In the CIDR context, the network prefix is the network component of an IP address. In IPv4 systems, the network component of a complete address is known as the 'network part', and the remaining part of the address is known as the 'host part'. In IPv6 systems, the network component of a complete address is known as the 'subnet prefix', and the remaining part is known as the 'interface identifier'.
ディスカッション：CIDR文脈において、ネットワークプレフィックスは、IPアドレスのネットワーク構成要素です。 IPv4のシステムでは、完全なアドレスのネットワーク構成要素は、「ネットワーク部」として知られており、アドレスの残りの部分は、「ホスト部」として知られています。 IPv6システムでは、完全なアドレスのネットワーク構成要素は、「サブネットプレフィックス」として知られており、残りの部分は「インタフェース識別子」として知られています。
Measurement units: N.A.
測定単位：N。A.
Issues:
問題：
See also:
参照してください：
Definition: The network prefix length is the number of bits, out of the total constituting the address field, that define the network prefix portion of the address.
定義：ネットワークプレフィックス長は、アドレスのネットワークプレフィックス部分を定義するアドレス・フィールドを構成する全体のうちビット数は、です。
Discussion: A common alternative to using a bit-wise mask to communicate this component is the use of slash (/) notation. This binds the notion of network prefix length in bits to an IP address. For example, 141.184.128.0/17 indicates that the network component of this IPv4 address is 17 bits wide. Similar notation is used for IPv6 network prefixes; e.g., 2001:db8:719f::/48. When referring to groups of addresses, the network prefix length is often used as a means of describing groups of addresses as an equivalence class. For example, 'one hundred /16 addresses' refers to 100 addresses whose network prefix length is 16 bits.
考察：このコンポーネントを通信するためにビット単位のマスクを使用する一般的な代替案は、スラッシュ（/）表記の使用です。これは、IPアドレスのビット内のネットワークプレフィックス長の概念をバインドします。例えば、141.184.128.0/17はこのIPv4アドレスのネットワークコンポーネントが17ビット幅であることを示しています。同様の表記は、IPv6ネットワークプレフィックスのために使用されます。例えば、2001：DB8：719f :: / 48。アドレスのグループに言及する場合、ネットワークプレフィックスの長さは、多くの場合、等価クラスとしてのアドレスのグループを記述する手段として使用されます。例えば、「百/ 16アドレスは」そのネットワークプレフィックス長は16ビットである100個のアドレスを指します。
Measurement units: Bits.
測定単位：ビット。
Issues:
問題：
See also: Network Prefix.
参照：ネットワークプレフィックスを。
Definition: In general, a 'route' is the n-tuple <prefix, nexthop [, other routing or non-routing protocol attributes]>. A route is not end-to-end, but is defined with respect to a specific next hop that should take packets on the next step toward their destination as defined by the prefix. In this usage, a route is the basic unit of information about a target destination distilled from routing protocols.
定義：一般的に、「経路」は、Nタプル<プレフィックス、ネクストホップ【、他のルーティングまたは非ルーティングプロトコル属性]>。ルートは、エンドツーエンドではなく、接頭語によって定義されるように、その宛先に向かって次のステップでパケットを取るべき特定の次のホップに関して定義されます。この使用法では、ルートは、ルーティングプロトコルから蒸留目標目的地に関する情報の基本単位です。
Discussion: This term refers to the concept of a route common to all routing protocols. With reference to the definition above, typical non-routing-protocol attributes would be associated with diffserv or traffic engineering.
ディスカッション：この用語は、すべてのルーティングプロトコルに共通のルートの概念です。上記の定義を参照して、典型的な非ルーティング・プロトコル属性は、DiffServのまたはトラフィックエンジニアリングに関連付けされるであろう。
Measurement units: N.A.
測定単位：N。A.
Issues: None.
問題：なし。
See also: BGP Route.
参照してください：BGPルートを。
Definition: A BGP route is an n-tuple <prefix, nexthop, ASpath [, other BGP attributes]>.
定義：BGPルートは、nタプル<プレフィックス、ネクストホップ、ASPATH【、他のBGP属性]>です。
Discussion: BGP Attributes, such as Nexthop or AS path, are defined in RFC 1771, where they are known as Path Attributes, and they are the qualifying data that define the route. From RFC 1771: "For purposes of this protocol a route is defined as a unit of information that pairs a destination with the attributes of a path to that destination."
議論は：BGPは、ネクストホップとして、またはパスAS、属性、パス属性としてそれらが知られているRFC 1771で定義されており、それらは、ルートを定義する修飾データです。 RFC 1771から「このプロトコルの目的のための経路は、ペアその宛先へのパスの属性を持つ宛先その情報の単位として定義されます。」
Measurement units: N.A.
測定単位：N。A.
Issues:
問題：
See also: Route, Prefix, Adj-RIB-In, Network Level Reachability Information (NLRI)
参照：ルート、プレフィックス、調整]-RIB-では、ネットワークレベル到達可能性情報（NLRI）
Definition: The NLRI consists of one or more network prefixes with the same set of path attributes.
定義：NLRIはパス属性の同じセットを持つ1つ以上のネットワークプレフィックスで構成されています。
Discussion: Each prefix in the NLRI is combined with the (common) path attributes to form a BGP route. The NLRI encapsulates a set of destinations to which packets can be routed (from this point in the network) along a common route described by the path attributes.
議論：NLRIの各プレフィックスは、（共通の）パスがBGPルートを形成する属性と組み合わされます。 NLRIは、パケットが、パス属性によって記述される一般的な経路に沿って（ネットワーク内のこの点から）ルーティング可能な目的地のセットをカプセル化します。
Measurement units: N.A.
測定単位：N。A.
Issues:
問題：
See also: Route Packing, Network Prefix, BGP Route, NLRI.
参照：パッキングルート、ネットワークプレフィックス、BGPルート、NLRI。
Definition: An UPDATE message contains an advertisement of a single NLRI field, possibly containing multiple prefixes, and multiple withdrawals of unfeasible routes. See RFC 1771 for details.
定義：UPDATEメッセージによっては複数のプレフィックス、および実行不可能なルートの複数の引き出しを含む、単一NLRI分野の広告が含まれています。詳細については、RFC 1771を参照してください。
Discussion: From RFC 1771: "A variable length sequence of path attributes is present in every UPDATE. Each path attribute is a triple <attribute type, attribute length, attribute value> of variable length."
議論：RFC 1771から「パスの可変長配列は、属性はすべての更新中に存在する各パス属性は可変長の三重<属性タイプ、属性長さ、属性値>です。」。
Measurement units: N.A.
測定単位：N。A.
See also:
参照してください：
The RIB collectively consists of a set of logically (not necessarily physically) distinct databases, each of which is enumerated below. The RIB contains all destination prefixes to which the router may forward, and one or more currently reachable next hop addresses for them.
RIBをまとめ以下に列挙されるこれらの各々は、論理的に（必ずしも物理的に）別個のデータベースの組、から成ります。 RIBは、すべてのルータが転送してもよい先の先のプレフィックス、およびそれらのための1つまたは複数の現在到達可能なネクストホップアドレスが含まれています。
Routes included in this set potentially have been selected from several sources of information, including hardware status, interior routing protocols, and exterior routing protocols. RFC 1812 contains a basic set of route selection criteria relevant in an all-source context. Many implementations impose additional criteria. A common implementation-specific criterion is the preference given to different routing information sources.
ルートは、潜在的に、ハードウェアステータス、内部ルーティングプロトコル、および外部ルーティングプロトコルを含む、いくつかの情報源から選択されたセットに含まれます。 RFC 1812は、すべてのソースのコンテキスト内の関連するルート選択基準の基本的なセットが含まれています。多くの実装では、追加の条件を課しています。一般的な実装に固有の判断基準は、異なるルーティング情報源に与えられる優先です。
Definition: Adj-RIB-In and Adj-RIB-Out are "views" of routing information from the perspective of individual peer routers. The Adj-RIB-In contains information advertised to the DUT by a specific peer.
定義：ADJ-RIB-InとのAdj-RIB-outが、個々のピアルータの観点からルーティング情報の「ビュー」です。 Adj-RIB-においては、特定のピアによってDUTへ広告情報を含みます。
The Adj-RIB-Out contains the information the DUT will advertise to the peer. See RFC 1771.
調整]-RIB-OutがDUTがピアにアドバタイズします情報が含まれています。 RFC 1771を参照してください。
Discussion:
討論：
Issues:
問題：
Measurement units: Number of route instances.
測定単位：ルートインスタンスの数。
See also: Route, BGP Route, Route Instance, Loc-RIB, FIB.
参照：ルート、BGPルート、ルートインスタンス、のLoc-RIB、FIB。
Definition: The Loc-RIB contains the set of best routes selected from the various Adj-RIBs, after applying local policies and the BGP route selection algorithm.
定義：のLoc-RIBは、ローカルポリシーおよびBGPルート選択アルゴリズムを適用した後、様々な調整]リブから選ば最適なルートのセットが含まれています。
Discussion: The separation implied among the various RIBs is logical. It does not necessarily follow that these RIBs are distinct and separate entities in any given implementation. Types of routes that need to be considered include internal BGP, external BGP, interface, static, and IGP routes.
ディスカッション：様々なのRIBの間で暗黙の分離は論理的です。必ずしもこれらのリブは、任意の実装で異なる別個の実体であるということにはなりません。考慮する必要がある経路の種類は内部BGP、外部BGP、インターフェース、静的、およびIGP経路が挙げられます。
Issues:
問題：
Measurement units: Number of routes.
測定単位：ルートの数。
See also: Route, BGP Route, Route Instance, Adj-RIB-In, Adj-RIB-Out, FIB.
参照：ルート、BGPルート、ルートインスタンス、調整]-RIB-で、調整]-RIBアウト、FIB。
Definition: Prefix Filtering is a technique for eliminating routes from consideration as candidates for entry into a RIB by matching the network prefix in a BGP Route against a list of network prefixes.
定義：プレフィックスフィルタリングネットワークプレフィックスのリストに対するBGPルート内のネットワークプレフィックスを照合することによってRIBへのエントリのための候補として考慮からルートを排除するための技術です。
Discussion: A BGP Route is eliminated if, for any filter prefix from the list, the Route prefix length is equal to or longer than the filter prefix length and the most significant bits of the two prefixes match over the length of the filter prefix. See 'Cooperative Route Filtering Capability for BGP-4' [BGP-4] for examples of usage.
議論：BGPルートはリストから任意のフィルタのプレフィックスのため、経路プレフィックス長に等しいか、フィルタのプレフィックスの長さよりも長く、2つのプレフィックスの最上位ビットは、フィルタのプレフィックスの長さにわたって一致する場合に除去されます。使用法の例については、[BGP-4]「BGP-4のための協調経路フィルタリング機能」を参照。
Measurement units: Number of filter prefixes; lengths of prefixes.
測定単位：フィルタプレフィックスの数。プレフィックスの長さ。
Issues:
問題：
See also: BGP Route, Network Prefix, Network Prefix Length, Routing Policy, Routing Policy Information Base.
参照：BGPルート、ネットワークプレフィックス、ネットワークプレフィックス長、ルーティングポリシー、ルーティングポリシー情報ベース。
Definition: Routing Policy is "the ability to define conditions for accepting, rejecting, and modifying routes received in advertisements" [GLSSRY].
定義：ルーティングポリシー[GLSSRY]「受け入れ拒否、および広告で受信したルートを変更するための条件を定義する能力」です。
Discussion: RFC 1771 further constrains policy to be within the hop-by-hop routing paradigm. Policy is implemented using filters and associated policy actions such as Prefix Filtering. Many ASes formulate and document their policies using the Routing Policy Specification Language (RPSL) [RFC2622] and then automatically generate configurations for the BGP processes in their routers from the RPSL specifications.
議論：RFC 1771はさらに、ホップバイホップルーティングパラダイム内にあるようにポリシーを拘束します。ポリシーは、フィルタや、プレフィックスフィルタリングなどの関連するポリシーアクションを使用して実装されています。多くのASが策定し、ルーティングポリシー仕様言語（RPSL）を使用してポリシーを文書[RFC2622]をして、自動的にRPSL仕様から自分のルータでBGPプロセスのためのコンフィギュレーションを生成します。
Measurement units: Number of policies; length of policies.
測定単位：ポリシーの数。ポリシーの長さ。
Issues:
問題：
See also: Routing Policy Information Base, Prefix Filtering.
参照してください：ルーティングポリシー情報ベース、プレフィックスフィルタリングを。
Definition: A routing policy information base is the set of incoming and outgoing policies.
定義：ルーティングポリシー情報ベースは、着信および発信ポリシーのセットです。
Discussion: All references to the phase of the BGP selection process below are made with respect to RFC 1771 definition of these phases. Incoming policies are applied in Phase 1 of the BGP selection process to the Adj-RIB-In routes to set the metric for the Phase 2 decision process. Outgoing Policies are applied in Phase 3 of the BGP process to the Adj-RIB-Out routes preceding route (prefix and path attribute tuple) announcements to a specific peer. Policies in the Policy Information Base have matching and action conditions. Common information to match includes route prefixes, AS paths, communities, etc. The action on match may be to drop the update and not to pass it to the Loc-RIB, or to modify the update in some way, such as changing local preference (on input) or MED (on output), adding or deleting communities, prepending the current AS in the AS path, etc. The amount of policy processing (both in terms of route maps and filter/access lists) will impact the convergence time and properties of the distributed BGP algorithm. The amount of policy processing may vary from a simple policy that accepts all routes and sends them according to a complex policy with a substantial fraction of the prefixes being filtered by filter/access lists.
ディスカッション：BGP選択プロセスのフェーズへのすべての参照は、以下のこれらの相のRFC 1771の定義に関して作られています。着信ポリシーは、フェーズ2の決定プロセスのメトリックを設定するのAdj-RIB-においてルートにBGP選択プロセスのフェーズ1で適用されます。発信ポリシーはルート（プレフィックスとパス属性タプル）特定のピアにアナウンスの前のAdj-RIBアウトルートにBGPプロセスの第3段階で適用されます。ポリシー情報ベースのポリシーは、一致するとアクションの条件を持っています。一致する共通情報が一致にアクションが更新をドロップする、および、Loc-RIBにそれを通過しない、またはそのような局所的な好みを変更するように、何らかの方法で更新を変更することができる等パス、コミュニティ、AS経路プレフィックスを含みます等、AS経路で電流ASを付加、ポリシー処理の量をコミュニティを追加または削除（両方のルートマップおよびフィルタ/アクセスリストに関して）、（入力上で）またはMED（出力上で）収束時間に影響を与えます分散BGPアルゴリズムの性質。ポリシー処理の量は、すべてのルートを受け入れ、フィルタ/アクセスリストによってフィルタリングされたプレフィクスのかなりの割合で複合ポリシーに従ってそれらを送信する単純なポリシーから変化してもよいです。
Measurement units: Number and length of policies.
測定単位：番号およびポリシーの長さ。
Issues:
問題：
See also:
参照してください：
Definition: According to the definition in Appendix B of RIPE-37 [RIPE37]: "The table containing the information necessary to forward IP Datagrams is called the Forwarding Information Base. At minimum, this contains the interface identifier and next hop information for each reachable destination network prefix."
定義：[RIPE37] RIPE37の付録Bの定義によると、「IPデータグラムを転送するのに必要な情報を含むテーブルを転送情報ベースと呼ばれる最低限、これは各到達するためのインターフェイス識別子と次ホップ情報を含みます。宛先ネットワークプレフィックス。」
Discussion: The forwarding information base describes a database indexing network prefixes versus router port identifiers. The forwarding information base is distinct from the "routing table" (the Routing Information Base or RIB), which holds all routing information received from routing peers. It is a data plane construct and is used for the forwarding of each packet. The Forwarding Information Base is generated from the RIB. For the purposes of this document, the FIB is effectively the subset of the RIB used by the forwarding plane to make per-packet forwarding decisions. Most current implementations have full, non-cached FIBs per router interface. All the route computation and convergence occurs before entries are downloaded into a FIB.
ディスカッション：転送情報ベースは、ルータのポート識別子対データベースのインデックス作成ネットワークプレフィックスを説明します。転送情報ベースは、ルーティングピアから受信したすべてのルーティング情報を保持し、「ルーティングテーブル」（ルーティング情報ベース、またはRIB）、区別されます。これは、データプレーン構造体であり、各パケットの転送に使用されます。転送情報ベースはRIBから生成されます。このドキュメントの目的のために、FIBは、効果的に、パケットごとの転送決定を行うためにフォワーディングプレーンで使用されるRIBのサブセットです。ほとんどの現在の実装では、ルータインターフェイスごとにフル、非キャッシュされたのFIBを持っています。エントリがFIBにダウンロードされる前に、すべてのルート計算と収束が発生します。
Measurement units: N.A.
測定単位：N。A.
Issues:
問題：
See also: Route, RIB.
参照：ルート、RIB。
Definition: A BGP instance is a process with a single Loc-RIB.
定義：BGPインスタンスは、単一のLoc-RIBとプロセスです。
Discussion: For example, a BGP instance would run in routers or test equipment. A test generator acting as multiple peers will typically run more than one instance of BGP. A router would typically run a single instance.
ディスカッション：たとえば、BGPインスタンスは、ルータや試験装置で実行されます。複数のピアを演技テストジェネレータは、通常、BGPの複数のインスタンスを実行します。ルータは、通常、単一のインスタンスを実行します。
Measurement units: N.A.
測定単位：N。A.
Issues:
問題：
See also:
参照してください：
Definition: A BGP device is a system that has one or more BGP instances running on it, each of which is responsible for executing the BGP state machine.
定義：BGPデバイスは、BGPステートマシンを実行する責任を負う各々がその上で実行されている一つまたは複数のBGPインスタンスを有するシステムです。
Discussion: We have chosen to use "device" as the general case, to deal with the understood (e.g., [GLSSRY]) and yet-to-be-invented cases where the control processing may be separate from forwarding [RFC2918]. A BGP device may be a traditional router, a route server, a BGP-aware traffic steering device, or a non-forwarding route reflector. BGP instances such as route reflectors or servers, for example, never forward traffic, so forwarding-based measurements would be meaningless for them.
考察：我々は、制御処理は[RFC2918]を転送から分離していてもよいと理解（例えば、[GLSSRY]）とまだツー考案する場合に対処するために、一般的なケースとして、「デバイス」を使用することを選択しました。 BGPデバイスは、従来のルータ、ルート・サーバ、BGP対応トラフィックステアリング装置、または非転送ルートリフレクタであってもよいです。そのようなルートリフレクタまたはサーバ、例えば、決してフォワードトラフィックので、転送ベースの測定としてBGPインスタンスは、彼らのために無意味であろう。
Measurement units: N.A.
測定単位：N。A.
Issues:
問題：
See also:
参照してください：
Definition: A BGP session is a session between two BGP instances.
定義：BGPセッションは、2つのBGPインスタンス間のセッションです。
Discussion:
討論：
Measurement units: N.A.
測定単位：N。A.
Issues:
問題：
See also:
参照してください：
Definition: An active BGP session is one that is in the established state. (See RFC 1771.)
定義：アクティブBGPセッションが確立した状態にあるものです。 （RFC 1771を参照してください）
Discussion:
討論：
Measurement units: N.A.
測定単位：N。A.
Issues:
問題：
See also:
参照してください：
Definition: A BGP peer is another BGP instance to which the DUT is in the Established state. (See RFC 1771.)
定義：BGPピアは、DUTが設立された状態にあるために別のBGPインスタンスです。 （RFC 1771を参照してください）
Discussion: In the test scenarios for the methodology discussion that will follow this document, peers send BGP advertisements to the DUT and receive DUT-originated advertisements. We recommend that the peering relation be established before tests begin. It might also be interesting to measure the time required to reach the established state. This is a protocol-specific definition, not to be confused with another frequent usage, which refers to the business/economic definition for the exchange of routes without financial compensation. It is worth noting that a BGP peer, by this definition, is associated with a BGP peering session, and there may be more than one such active session on a router or on a tester. The peering sessions referred to here may exist between various classes of BGP routers (see Section 4.2).
ディスカッション：この文書に続く方法論の議論のためのテストシナリオでは、ピアは、DUTへのBGPアドバタイズメントを送信し、DUT由来の広告を受け取ります。私たちは、テストが始まる前に、ピアリング関係が確立されることをお勧めします。また、確立状態に到達するのに必要な時間を測定することも面白いかもしれません。これは、経済的な補償なしでルートを交換するためのビジネス/経済的な定義を意味別の頻繁な使用と混同すべきではないプロトコル固有の定義です。 BGPピアが、この定義によって、BGPピアリング・セッションに関連付けられていることは注目に値する、およびルータまたはテスタに複数のそのようなアクティブなセッションが存在してもよいです。ここでいうピアリング・セッション（セクション4.2を参照）BGPルータの種々のクラスの間に存在してもよいです。
Measurement units: Number of BGP peers.
測定単位：BGPピアの数。
Issues:
問題：
See also:
参照してください：
Definition: A BGP neighbor is a device that can be configured as a BGP peer.
定義：BGPネイバーは、BGPピアとして構成することができる装置です。
Discussion:
討論：
Measurement units:
測定単位：
Issues:
問題：
See also:
参照してください：
Definition: (Paraphrased from RFC 1771) The MRAI timer determines the minimum time between advertisements of routes to a particular destination (prefix) from a single BGP device. The timer is applied on a pre-prefix basis, although the timer is set on a per-BGP device basis.
定義：（RFC 1771から言い換え）MRAIタイマは単一BGPデバイスから特定の宛先（接頭語）へのルートの広告との間の最小時間を決定します。タイマーがあたり-BGPデバイスごとに設定されているが、タイマーは、事前プレフィックス単位で適用されます。
Discussion: Given that a BGP instance may manage in excess of 100,000 routes, RFC 1771 allows for a degree of optimization in order to limit the number of timers needed. The MRAI does not apply to routes received from BGP speakers in the same AS or to explicit withdrawals. RFC 1771 also recommends that random jitter is applied to MRAI in an attempt to avoid synchronization effects between the BGP instances in a network. In this document, we define routing plane convergence by measuring from the time an NLRI is advertised to the DUT to the time it is advertised from the DUT. Clearly any delay inserted by the MRAI will have a significant effect on this measurement.
ディスカッション：BGPインスタンス100,000ルートの過剰に管理することができることを考えると、RFC 1771は、必要なタイマーの数を制限するために最適化度を可能にします。 MRAIは同じASにまたは明示的な引き出しにBGPスピーカから受信したルートには適用されません。 RFC 1771は、ランダムジッタは、ネットワーク内のBGPインスタンス間の同期の影響を避けるための試みでMRAIに適用されることをお勧めします。この文書では、我々は、NLRIは、それがDUTからアドバタイズされた時にDUTにアドバタイズされた時点から測定することによって、平面収束ルーティング定義します。明らかにMRAIによって挿入された任意の遅延は、この測定値に大きな影響を持つことになります。
Measurement units: Seconds.
測定単位：秒。
Issues:
問題：
See also: NLRI, BGP Route.
参照：NLRI、BGPルート。
Definition: The MAOI specifies the minimum interval between advertisements of locally originated routes from this BGP instance.
定義：MAOIが局所的に、このBGPインスタンスからルートを発信する広告との間の最小間隔を指定します。
Discussion: Random jitter is applied to MAOI in an attempt to avoid synchronization effects between BGP instances in a network.
ディスカッション：ランダム・ジッタは、ネットワーク内のBGPインスタンス間の同期の影響を避けるための試みでMAOIに適用されます。
Measurement units: Seconds.
測定単位：秒。
Issues: It is not known what, if any, relationship exists between the settings of MRAI and MAOI.
問題：あれば、関係がMRAIとMAOIの設定の間に存在するものを、知られていません。
See also: MRAI, BGP Route.
参照：MRAI、BGPルート。
Definition: Route for which there is a FIB entry corresponding to a RIB entry.
定義：ルートRIBのエントリに対応するFIBエントリが存在しているため。
Discussion:
討論：
Measurement units: Number of routes.
測定単位：ルートの数。
Issues:
問題：
See also: RIB.
参照：RIBを。
Definition: A unique route is a prefix for which there is just one route instance across all Adj-Ribs-In.
定義：ユニークなルートがすべてのAdj-リブイン間でちょうど1つのルートのインスタンスが存在するための接頭辞です。
Discussion:
討論：
Measurement units: N.A.
測定単位：N。A.
Issues:
問題：
See also: Route, Route Instance.
参照：ルート、ルートインスタンス。
Definition: A non-unique route is a prefix for which there is at least one other route in a set including more than one Adj-RIB-In.
定義：非ユニークなルートが複数の調整]-RIB-に含むセットに少なくとも1つの他のルートが存在するための接頭辞です。
Discussion:
討論：
Measurement units: N.A.
測定単位：N。A.
Issues:
問題：
See also: Route, Route Instance, Unique Active Route.
参照：ルート、ルートインスタンス、ユニークなアクティブなルートを。
Definition: A route instance is one of several possible occurrences of a route for a particular prefix.
定義：ルートのインスタンスは、特定のプレフィックスのための経路のいくつかの可能な出現の一つです。
Discussion: When a router has multiple peers from which it accepts routes, routes to the same prefix may be received from several peers. This is then an example of multiple route instances. Each route instance is associated with a specific peer. The BGP algorithm that arbitrates between the available candidate route instances may reject a specific route instance due to local policy.
議論：ルータは、それがルートを受け入れ、そこから複数のピアを有する場合、同じプレフィックスへのルートが複数のピアから受信することができます。これは、複数のルート・インスタンスの一例です。各ルート・インスタンスは、特定のピアに関連付けられています。利用可能な候補経路インスタンス間調停BGPアルゴリズムにより、ローカルポリシーに特定のルートインスタンスを拒否することができます。
Measurement units: Number of route instances.
測定単位：ルートインスタンスの数。
Issues: The number of route instances in the Adj-RIB-In bases will vary based on the function to be performed by a router. An inter-provider border router, located in the default-free zone (see Section 4.1.4), will likely receive more route instances than a provider edge router, located closer to the end-users of the network.
問題：のAdj-RIB-Inの塩基の経路インスタンスの数は、ルータによって実行される機能に基づいて変化するであろう。デフォルト・フリーゾーンに位置間プロバイダーの境界ルータは、おそらくネットワークのエンドユーザーに近い位置にプロバイダ・エッジ・ルータ、より多くのルートインスタンスを受け取ります（4.1.4項を参照してください）。
See also:
参照してください：
Many terms included in this list of definitions were originally described in previous standards or papers. They are included here because of their pertinence to this discussion. Where relevant, reference is made to these sources. An effort has been made to keep this list complete with regard to the necessary concepts without over-definition.
定義のこのリストに含まれ、多くの用語はもともと、従来の規格や論文に記載されました。彼らはこのための議論にその妥当でここに含まれています。関連する場合、参照は、これらのソースに行われます。努力は、オーバー定義せずに必要な概念についての完全なリストを維持するために行われています。
An individual router's routing table may not necessarily contain a default route. Not having a default route, however, is not synonymous with having a full default-free table (DFT). Also, a router that has a full set of routes as in a DFT, but that also has a 'discard' rule for a default route would not be considered default free.
個々のルータのルーティングテーブルは、必ずしもデフォルトルートを含めることはできません。デフォルトルートを持っていない、しかし、完全なデフォルトフリーテーブル（DFT）を有すると同義ではありません。また、DFTのようにルートのフルセットを持っている、しかし、それはまた、デフォルトルートの「廃棄」のルールを持っているルータは、デフォルトの自由とは見なされません。
Note that in this section the references to number of routes are to routes installed in the loc-RIB, which are therefore unique routes, not route instances. Also note that the total number of route instances may be 4 to 10 times the number of routes.
このセクション内のルートの数への言及は、従って一意のルートではなく、ルートインスタンスでLOC-RIBにインストールされたルートにあることに留意されたいです。また、ルート・インスタンスの総数はルートの4〜10倍の数であってもよいことに留意されたいです。
Definition: A default route can match any destination address. If a router does not have a more specific route for a particular packet's destination address, it forwards this packet to the next hop in the default route entry, provided that its Forwarding Table (Forwarding Information Base, or FIB, contains one). The notation for a default route for IPv4 is 0.0.0.0/0 and for IPv6 it is 0:0:0:0:0:0:0:0 or ::/0.
定義：デフォルトルートは、任意の宛先アドレスを一致させることができます。ルータが特定のパケットの宛先アドレスのためのより具体的なルートを持っていない場合、それはデフォルトのルートエントリの次のホップにこのパケットを転送し、その転送テーブル（転送情報ベース、またはFIBは、1が含まれている）ことを条件とします。 IPv4のデフォルトルートの表記は0.0.0.0/0であり、IPv6のためのそれは0：0：0：0：0：0：0：0または:: / 0。
Discussion:
討論：
Measurement units: N.A.
測定単位：N。A.
Issues:
問題：
See also: Default-Free Routing Table, Route, Route Instance.
参照：デフォルトのフリールーティングテーブル、ルート、ルートインスタンス。
Definition: A default-free routing table has no default routes and is typically seen in routers in the core or top tier of routers in the network.
定義：デフォルトフリールーティングテーブルは、デフォルトルートを持っていないと、典型的には、ネットワーク内のルータのコア又はトップ層でルータに見られます。
Discussion: The term originates from the concept that routers at the core or top tier of the Internet will not be configured with a default route (Notation in IPv4 0.0.0.0/0 and in IPv6 0:0:0:0:0:0:0:0 or ::/0). Thus they will forward every packet to a specific next hop based on the longest match between the destination IP address and the routes in the forwarding table.
議論は：0：0：0：0：0という用語は、コアまたはインターネットの一流のルータは、IPv4とIPv6の0.0.0.0/0に0にデフォルトルート（表記で構成されないであろうという概念に由来します：0：0または:: / 0）。したがって彼らは、宛先IPアドレスおよび転送テーブル内のルートの間の最長一致に基づいて特定の次のホップにすべてのパケットを転送します。
Default-free routing table size is commonly used as an indicator of the magnitude of reachable Internet address space. However, default-free routing tables may also include routes internal to the router's AS.
デフォルトフリーのルーティングテーブルのサイズは、一般的に到達可能なインターネットアドレス空間の大きさの指標として使用されています。ただし、デフォルトのフリールーティングテーブルには、ルータのAS内部のルートを含むこともできます。
Measurement units: The number of routes.
測定単位：ルートの数。
See also: Full Default-Free Table, Default Route.
参照してください：フルデフォルトフリー表、ルートのデフォルト。
Definition: A full default-free table is the union of all sets of BGP routes taken from all the default-free BGP routing tables collectively announced by the complete set of autonomous systems making up the public Internet. Due to the dynamic nature of the Internet, the exact size and composition of this table may vary slightly depending on where and when it is observed.
定義：フルデフォルトフリーテーブルをまとめ、パブリックインターネットを構成する自律システムの完全なセットが発表したすべてのデフォルトの無BGPルーティングテーブルから取られたBGPルートのすべての和集合です。インターネットの動的な性質のために、このテーブルの正確なサイズおよび組成は、いつどこでそれが観察されるに応じてわずかに変化してもよいです。
Discussion: It is generally accepted that a full table, in this usage, does not contain the infrastructure routes or individual sub-aggregates of routes that are otherwise aggregated by the provider before announcement to other autonomous systems.
議論：それは、一般的に完全なテーブルは、この使用法では、インフラストラクチャのルートまたはそうでなければ、他の自律システムに発表する前に、プロバイダによって集約される経路の個々のサブ凝集体を含有しないことが認められています。
Measurement units: Number of routes.
測定単位：ルートの数。
Issues: The full default-free routing table is not the same as the union of all reachable unicast addresses. The table simply does not contain the default prefix (0/0) and does contain the union of all sets of BGP routes from default-free BGP routing tables.
問題：フルデフォルトフリールーティングテーブルのすべての到達可能なユニキャストアドレスの労働組合と同じではありません。テーブルには、単にデフォルトの接頭辞（0/0）が含まれていないと、デフォルトの無BGPルーティングテーブルからBGPルートのすべての和集合を含んでいません。
See also: Routes, Route Instances, Default Route.
参照：ルート、ルートインスタンス、デフォルトルート。
Definition: The default-free zone is the part of the Internet backbone that does not have a default route.
定義：デフォルトフリーゾーンは、デフォルトルートを持っていないインターネットバックボーンの一部です。
Discussion:
討論：
Measurement units:
測定単位：
Issues:
問題：
See also: Default Route.
参照：ルートのデフォルト。
Definition: A full provider-internal table is a superset of the full routing table that contains infrastructure and non-aggregated routes.
定義：フルプロバイダの内部テーブルは、インフラストラクチャと非凝集ルートが含まれている完全なルーティングテーブルのスーパーセットです。
Discussion: Experience has shown that this table might contain 1.3 to 1.5 times the number of routes in the externally visible full table. Tables of this size, therefore, are a real-world requirement for key internal provider routers.
ディスカッション：経験は、この表には、外部から見える完全なテーブル内のルートの1.3から1.5倍の数が含まれている可能性があることを示しています。このサイズのテーブルは、そのため、キー内部プロバイダ・ルータのための実世界の要件です。
Measurement units: Number of routes.
測定単位：ルートの数。
Issues:
問題：
See also: Routes, Route Instances, Default Route.
参照：ルート、ルートインスタンス、デフォルトルート。
A given router may perform more than one of the following functions, based on its logical location in the network.
特定のルータは、ネットワーク内の論理的な位置に基づいて、以下の機能の複数を実行することができます。
Definition: A provider edge router is a router at the edge of a provider's network that speaks eBGP to a BGP speaker in another AS.
定義：プロバイダーエッジルータは、別のAS内のBGPスピーカーにのeBGPを話すプロバイダのネットワークのエッジにあるルータです。
Discussion: The traffic that transits this router may be destined to or may originate from non-adjacent autonomous systems. In particular, the MED values used in the Provider Edge Router would not be visible in the non-adjacent autonomous systems. Such a router will always speak eBGP and may speak iBGP.
ディスカッション：このルータを通過するトラフィックが宛てされ得るか、または非隣接の自律システムに由来してもよいです。具体的には、プロバイダーエッジルータで使用されるMED値は、非隣接自律システムに見えません。このようなルータはいつものeBGPを話すだろうとのiBGPを話すことがあります。
Measurement units:
測定単位：
Issues:
問題：
See also:
参照してください：
Definition: A subscriber edge router is router at the edge of the subscriber's network that speaks eBGP to its provider's AS(s).
定義：加入者のエッジルータは、そのプロバイダのAS（複数可）へのeBGPを話す加入者のネットワークのエッジにあるルータです。
Discussion: The router belongs to an end user organization that may be multi-homed, and that carries traffic only to and from that end user AS. Such a router will always speak eBGP and may speak iBGP.
ディスカッション：ルータは、マルチホームすることができるエンドユーザ組織に属し、それが唯一のASにして、エンドユーザーからのトラフィックを運びます。このようなルータはいつものeBGPを話すだろうとのiBGPを話すことがあります。
Measurement units:
測定単位：
Issues: This definition of an enterprise border router (which is what most Subscriber Edge Routers are) is practical rather than rigorous. It is meant to draw attention to the reality that many enterprises may need a BGP speaker that advertises their own routes and accepts either default alone or partial routes. In such cases, they may be interested in benchmarks that use a partial routing table, to see whether a smaller control plane processor will meet their needs.
問題：（ほとんどの加入者エッジルータが何であるかである）は、エンタープライズ境界ルータのこの定義は実用的ではなく、厳しいです。多くの企業が独自のルートをアドバタイズし、単独のデフォルトまたは部分ルートのどちらかを受け入れBGPスピーカを必要とすることが現実に注意を引くためのものです。このような場合、彼らは、より小さな制御プレーンプロセッサは、それらのニーズを満たすかどうかを確認するために、部分的なルーティングテーブルを使用するベンチマークに興味があるかもしれません。
See also:
参照してください：
Definition: An inter-provider border router is a BGP speaking router that maintains BGP sessions with other BGP speaking routers in other providers' ASes.
定義：インタープロバイダの境界ルータは、他のプロバイダののAS内の他のBGPスピーキングルータでBGPセッションを維持BGPスピーキングルータです。
Discussion: Traffic transiting this router may be originated in or destined for another AS that has no direct connectivity with this provider's AS. Such a router will always speak eBGP and may speak iBGP.
ディスカッション：交通このルータを通過するには、発祥のかそれがこのプロバイダのASとは直接接続していないので、別の宛てすることができます。このようなルータはいつものeBGPを話すだろうとのiBGPを話すことがあります。
Measurement units:
測定単位：
Issues:
問題：
See also:
参照してください：
Definition: An core router is a provider router internal to the provider's net, speaking iBGP to that provider's edge routers, other intra-provider core routers, or the provider's inter-provider border routers.
定義：コアルータは、そのプロバイダのエッジルータ、他のイントラプロバイダーのコアルータ、またはプロバイダの間のプロバイダの境界ルータへのiBGPを話す、プロバイダーのネットへの内部プロバイダルータです。
Discussion: Such a router will always speak iBGP and may speak eBGP.
ディスカッション：このようなルータはいつものiBGPを話すだろうとのeBGPを話すことがあります。
Measurement units:
測定単位：
Issues: By this definition, the DUTs that are eBGP routers aren't core routers.
問題：この定義では、BGPルータあるダクトは、コアルータではありません。
See also:
参照してください：
This section contains a sequence of definitions that build up to the definition of an update train. The packet train concept was originally introduced by Jain and Routhier [PKTTRAIN]. It is here adapted to refer to a train of packets of interest in BGP performance testing.
このセクションでは、更新列の定義に構築定義のシーケンスが含まれています。パケット列の概念は、もともとジャイナ教とRouthier [PKTTRAIN]によって導入されました。ここではBGPのパフォーマンステストへの関心のパケット列を参照するようになっています。
This is a formalization of the sort of test stimulus that is expected as input to a DUT running BGP. This data could be a well-characterized, ordered, and timed set of hand-crafted BGP UPDATE packets. It could just as well be a set of BGP UPDATE packets that have been captured from a live router.
これは、BGPを実行しているDUTへの入力として期待されているテスト刺激の一種の形式化です。このデータは、十分に特徴付けられ、順序付け、及び手作りBGPアップデートパケットのセット時限とすることができます。それはちょうどだけでなく、ライブルータから撮影されたBGPのUPDATEパケットの集合である可能性があります。
Characterization of route mixtures and update trains is an open area of research. The particular question of interest for this work is the identification of suitable update trains, modeled on or taken from live traces that reflect realistic sequences of UPDATEs and their contents.
ルート混合物および更新列車の特徴付けは、研究のオープンエリアです。この作品のために関心のある特定の問題は、適切な更新電車をモデルまたは更新とその内容の現実的なシーケンスを反映し、ライブトレースから取られたの同定です。
Definition: Route packing is the number of route prefixes accommodated in a single Routing Protocol UPDATE Message, either as updates (additions or modifications) or as withdrawals.
定義：ルートパッキングのいずれかの更新（追加または変更）または引き出しのように、単一のルーティングプロトコル更新メッセージに収容経路プレフィックスの数です。
Discussion: In general, a routing protocol update may contain more than one prefix. In BGP, a single UPDATE may contain two sets of multiple network prefixes: one set of additions and updates with identical attributes (the NLRI) and one set of unfeasible routes to be withdrawn.
議論は、一般に、ルーティングプロトコルの更新は、複数のプレフィックスを含んでいてもよいです。同一の属性を持つ追加および更新の一組（NLRI）と引き抜かれるべき不可能経路の一組：BGPにおいて、単一の更新は、複数のネットワークプレフィックスの二組を含むことができます。
Measurement units:
測定単位：
Number of prefixes.
プレフィックスの数。
Issues:
問題：
See also: Route, BGP Route, Route Instance, Update Train, NLRI.
参照：ルート、BGPルート、ルートインスタンス、更新列車、NLRI。
Definition: A route mixture is the demographics of a set of routes.
定義：ルート混合物はルートのセットの人口統計です。
Discussion: A route mixture is the input data for the benchmark. The particular route mixture used as input must be selected to suit the question being asked of the benchmark. Data containing simple route mixtures might be suitable to test the performance limits of the BGP device. Using live data or input that simulates live data will improve understanding of how the BGP device will operate in a live network. The data for this kind of test must be route mixtures that model the patterns of arriving control traffic in the live Internet. To accomplish this kind of modeling, it is necessary to identify the key parameters that characterize a live Internet route mixture. The parameters and how they interact is an open research problem. However, we identify the following as affecting the route mixture:
ディスカッション：ルートの混合物は、ベンチマークのための入力データです。入力として使用される特定の経路混合物は、ベンチマークの求められている質問を合わせて選択する必要があります。単純なルートの混合物を含むデータは、BGP装置の性能限界を試験するのに適したかもしれません。ライブデータをシミュレートし、ライブデータや入力を使用すると、BGPデバイスが実稼動中のネットワークでどのように動作するかの理解を向上させます。テストのこの種のデータは、ライブ、インターネットで制御トラフィックを到着のパターンをモデルルートの混合物でなければなりません。モデリングのこの種を達成するために、ライブのインターネットルートの混合物を特徴づける重要なパラメータを識別することが必要です。パラメータとどのようにそれらが相互作用は、オープンな研究課題です。しかし、我々はルートの混合物に影響を与えるとして、次の識別します：
* Path length distribution
*パスの長さの分布
* Attribute distribution
*属性の分布
* Prefix length distribution
*プレフィックス長分布
* Packet packing
*パケット梱包
* Probability density function of inter-arrival times of UPDATES
更新の間到着時間の*確率密度関数
Each of the items above is more complex than a single number. For example, one could consider the distribution of prefixes by AS or by length.
上記の各項目は、単一の数よりも複雑です。例えば、1は、ASまたは長さプレフィックスの分布を検討することもでき。
Measurement units: Probability density functions.
測定単位：確率密度関数。
Issues:
問題：
See also: NLRI, RIB.
参照：NLRI、RIBを。
Definition: An update train is a set of Routing Protocol UPDATE messages sent by a router to a BGP peer.
定義：更新列車はBGPピアにルータによって送信されるルーティングプロトコルのUPDATEメッセージのセットです。
Discussion: The arrival pattern of UPDATEs can be influenced by many things, including TCP parameters, hold-down timers, upstream processing, a peer coming up, or multiple peers sending at the same time. Network conditions such as a local or remote peer flapping a link can also affect the arrival pattern.
ディスカッション：更新の到着パターンが同時に送信するTCPパラメータ、ホールドダウンタイマー、上流の処理、来るピア、または複数のピアを含む多くの事、によって影響を受ける可能性があります。リンク羽ばたき、ローカルまたはリモートピアなどのネットワーク条件も到着パターンに影響を与えることができます。
Measurement units: Probability density function for the inter-arrival times of UPDATE packets in the train.
測定単位：列車でUPDATEパケットの到着時間の確率密度関数。
Issues: Characterizing the profiles of real-world UPDATE trains is a matter for future research. In order to generate realistic UPDATE trains as test stimuli, a formal mathematical scheme or a proven heuristic is needed to drive the selection of prefixes. Whatever mechanism is selected, it must generate update trains that have similar characteristics to those measured in live networks.
問題：実世界のUPDATE列車のプロファイルを特徴付けるには、今後の研究のための問題です。テスト刺激として現実的なUPDATE列を生成するために、正式な数学的手法や実績のあるヒューリスティックは、プレフィックスの選択を駆動するために必要とされます。どのようなメカニズムが選択され、それがライブネットワークで測定されたものと同様の特性を持って更新列を生成する必要があります。
See also: Route Mixture, MRAI, MAOI.
参照してください：ルート混合物、MRAI、国。
As we have seen from the previous sections, an update train used as a test stimulus has a considerable number of parameters that can be varied, to a greater or lesser extent, randomly and independently.
我々は、前のセクションから見てきたように、テスト刺激として使用される更新列がランダムにかつ独立して、多かれ少なかれ、変化させることができるパラメータのかなりの数を有しています。
A random update train will contain a route mixture randomized across:
ランダム更新列車が渡ってランダム化されたルートの混合物が含まれます。
* NLRIs
*たNLRI
* updates and withdrawals
*更新と引き出し
* prefixes
*接頭辞
* inter-arrival times of the UPDATEs and possibly across other variables.
*更新の可能性と他の変数間の相互到着時間。
This is intended to simulate the unpredictable asynchronous nature of the network, whereby UPDATE packets may have arbitrary contents and be delivered at random times.
これは、アップデートパケットは、任意のコンテンツを有していてもよいし、ランダムな時間に配信されるネットワークの予測不可能な非同期性をシミュレートすることを意図しています。
It is important that the data set be randomized sufficiently to avoid favoring one vendor's implementation over another's. Specifically, the distribution of prefixes could be structured to favor the internal organization of the routes in a particular vendor's databases. This is to be avoided.
データセットが別の上で1つのベンダーの実装を有利に回避するために、十分にランダム化されることが重要です。具体的には、接頭辞の分布は、特定のベンダーのデータベース内のルートの内部組織を優先するように構成することができます。これは避けるべきです。
Definition: A route flap is a change of state (withdrawal, announcement, attribute change) for a route.
定義：ルートフラップルートの状態の変化（撤退、発表、属性変更）です。
Discussion: Route flapping can be considered a special and pathological case of update trains. A practical interpretation of what may be considered excessively rapid is the RIPE 229 [RIPE229], which contains current guidelines on flap-damping parameters.
ディスカッション：ルートがフラッピングは、更新列車の特別なおよび病理学的なケースと考えることができます。過度に急速に考えることができるものの実用的な解釈は、フラップ減衰パラメータの現在のガイドラインが含まRIPE 229 [RIPE229]、です。
Measurement units: Flapping events per unit time.
測定単位：単位時間当たりのフラッピングイベント。
Issues: Specific Flap events can be found in Section 6.1. A bench-marker SHOULD use a mixture of different route change events in testing.
問題：特定のフラップイベントは、6.1節に記載されています。ベンチマーカーは、試験中に異なる経路変更イベントの混合物を使用すべきです。
See also: Route Change Events, Flap Damping, Packet Train
参照：ルート変更イベントを、フラップダンピング、パケット列
The following two definitions are central to the benchmarking of external routing convergence and are therefore singled out for more extensive discussion.
次の二つの定義は、外部ルーティング収束のベンチマークの中心であり、したがって、より広範な議論のために選抜されます。
A taxonomy characterizing routing information changes seen in operational networks is proposed in RIPE-37 [RIPE37] and Labovitz et al [INSTBLTY]. These papers describe BGP protocol-centric events and event sequences in the course of an analysis of network behavior. The terminology in the two papers categorizes similar but slightly different behaviors with some overlap. We would like to apply these taxonomies to categorize the tests under definition where possible, because these tests must tie in to phenomena that arise in actual networks. We avail ourselves of, or may extend, this terminology as necessary for this purpose.
運用ネットワークに見られるルーティング情報の変更を特徴付ける分類はRIPE37 [RIPE37]とLabovitzら[INSTBLTY]で提案されています。これらの論文は、ネットワークの挙動の解析の過程でBGPプロトコル中心のイベントとイベント・シーケンスを説明します。 2つの論文での用語は、いくつかの重複と類似しているが、わずかに異なる行動を分類します。これらのテストは、実際のネットワークで発生する現象に結びつける必要がありますので、私たちは、可能な限り定義の下でテストを分類するためにこれらの分類法を適用したいと思います。我々は、この目的のために、必要に応じて、この用語の自分自身を役に立つ、または延長することができます。
A route can be changed implicitly by replacing it with another route or explicitly by withdrawal followed by the introduction of a new route. In either case, the change may be an actual change, no change, or a duplicate. The notation and definition of individual categorizable route change events is adopted from [INSTBLTY] and given below.
ルートは、別のルートにまたは明示的に新しい経路の導入に続いての撤退により、それを交換することによって暗黙的に変更することができます。いずれの場合においても、変化が実際の変化、変化なし、または重複してもよいです。表記法及び個々categorizable経路変更イベントの定義は、[INSTBLTY]から採用し、以下に与えられます。
1. AADiff: Implicit withdrawal of a route and replacement by a route different in some path attribute.
1. AADiff：いくつかのパス属性の異なる経路でルートや交換の暗黙的撤退。
2. AADup: Implicit withdrawal of a route and replacement by route that is identical in all path attributes.
2. AADup：すべてのパスの属性が同一である経路による経路及び置換の暗黙撤退。
3. WADiff: Explicit withdrawal of a route and replacement by a different route.
3. WADiff：別の経路による経路や交換の明示的な撤退。
4. WADup: Explicit withdrawal of a route and replacement by a route that is identical in all path attributes.
4. WADup：すべてのパスの属性が同一である経路による経路及び交換の明示的な撤退。
To apply this taxonomy in the benchmarking context, we need terms to describe the sequence of events from the update train perspective, as listed above, and event indications in the time domain in order to measure activity from the perspective of the DUT. With this in mind, we incorporate and extend the definitions of [INSTBLTY] to the following:
ベンチマークのコンテキストでこの分類を適用するために、我々は、DUTの視点から活動を測定するために、上記のように、更新列車の視点からイベントの順序を記述するための用語を必要とし、時間領域でのイベントの表示。これを念頭において、私たちは次のように[INSTBLTY]の定義を組み込み、拡張します：
1. Tup (TDx): Route advertised to the DUT by Test Device x
1. Tupを（TDX）：ルートテスト装置XによってDUTにアドバタイズ
2. Tdown(TDx): Route being withdrawn by Device x
2. TDOWN（TDX）：ルートがデバイスXによって引き出されます
3. Tupinit(TDx): The initial announcement of a route to a unique prefix
3. Tupinit（TDX）：ユニークな接頭語へのルートの最初の発表
4. TWF(TDx): Route fail over after an explicit withdrawal.
4. TWF（TDX）：ルートは、明示的な撤退後にフェイルオーバーします。
But we need to take this a step further. Each of these events can involve a single route, a "short" packet train, or a "full" routing table. We further extend the notation to indicate how many routes are conveyed by the events above:
しかし、我々はさらに一歩これを取る必要があります。これらの各イベントは、単一のルート、「短い」パケット列、または「フル」、ルーティングテーブルを含むことができます。我々はさらに、上記イベントによって搬送されるどのように多くの経路を示すために表記を延ばします。
1. Tup(1,TDx) means Device x sends 1 route
1. Tupを（1、TDX）は、デバイスxが1つの経路を送信する手段と
2. Tup(S,TDx) means Device x sends a train, S, of routes
2. Tupを（S、TDX）は、デバイスXがルートの、列車、Sを送信する手段と
3. Tup(DFT,TDx) means Device x sends an approximation of a full default-free table.
3. Tupを（DFT、TDX）は、デバイスXが完全デフォルトフリーテーブルの近似値を送信します。
The basic criterion for selecting a "better" route is the final tiebreaker defined in RFC 1771, the router ID. As a consequence, this memorandum uses the following descriptor events, which are routes selected by the BGP selection process rather than simple updates:
「より良い」ルートを選択するための基本的な基準は、RFC 1771、ルータIDで定義された最後のタイブレークです。その結果、この覚書ではなく、単純なアップデートよりBGP選択プロセスで選択された経路である次の記述子のイベントを、使用しています。
1. Tbest -- The current best path.
1. Tbest - 現在のベストパス。
2. Tbetter -- Advertise a path that is better than Tbest.
2. Tbetter - Tbestよりも優れているパスをアドバタイズします。
3. Tworse -- Advertise a path that is worse than Tbest.
3. Tworse - Tbestより悪いパスをアドバタイズします。
Definition: A routing device is said to have converged at the point in time when the DUT has performed all actions in the control plane needed to react to changes in topology in the context of the test condition.
定義：ルーティングデバイスは、DUTは、試験条件の文脈におけるトポロジーの変化に反応するために必要な制御プレーン内のすべてのアクションを実行した時点で収束したと言われています。
Discussion: For example, when considering BGP convergence, the convergence resulting from a change that alters the best route instance for a single prefix at a router would be deemed to have occurred when this route is advertised to its downstream peers. By way of contrast, OSPF convergence concludes when SPF calculations have been performed and the required link states are advertised onward. The convergence process, in general, can be subdivided into three distinct phases:
議論は：BGPの収束を検討する際に、例えば、ルータでの単一のプレフィックスのための最適なルートインスタンスを変える変化に起因する収束がこのルートは、その下流のピアにアドバタイズされたときに発生したものとみなされます。 SPFの計算が行われていると、必要なリンク状態が以降アドバタイズされたときに対照的に、OSPFの収束が終了します。収束プロセスは、一般的には、3の異なる段階に細分化することができます。
* convergence across the entire Internet,
*インターネット全体の収束、
* convergence within an Autonomous System,
*自律システム内の収束、
* convergence with respect to a single device.
*単一のデバイスに対して収束。
Convergence with respect to a single device can be
単一のデバイスに対して収束することができます
* convergence with regard to data forwarding process(es)
*データ転送処理に関して収束（ES）
* convergence with regard to the routing process(es), the focus of this document.
*ルーティングプロセス（ES）、この文書の焦点に関して収束。
It is the latter that we describe herein and in the methodology documents. Because we are trying to benchmark the routing protocol performance, which is only a part of the device overall, this definition is intended (as far as is possible) to exclude any additional time needed to download and install the forwarding information base in the data plane. This definition is usable for different families of protocols.
それは我々がここと方法論の文書に記述し、後者です。我々はベンチマークにしようとしているので（可能な限りのように）この定義が意図され、装置全体の一部に過ぎないルーティングプロトコルのパフォーマンスは、データプレーンに転送情報ベースをダウンロードしてインストールするために必要な追加の時間を除外するために。この定義は、プロトコルの異なる家族のために使用可能です。
It is of key importance to benchmark the performance of each phase of convergence separately before proceeding to a composite characterization of routing convergence, where implementation-specific dependencies are allowed to interact. Care also needs to be taken to ensure that the convergence time is not influenced by policy processing on downstream peers. The time resolution needed to measure the device convergence depends to some extent on the types of the interfaces on the router. For modern routers with gigabit or faster interfaces, an individual UPDATE may be processed and re-advertised in very much less than a millisecond so that time measurements must be made to a resolution of hundreds to tens of microseconds or better.
それは別々に実装固有の依存関係が相互作用することが許可されているルーティング収束の複合特徴付けに進む前に、ベンチマークに重要な鍵の収束の各相の性能です。ケアも収束時間が下流ピア上のポリシー処理の影響を受けないように注意する必要があります。デバイスコンバージェンスを測定するのに必要な時間分解能は、ルータ上のインターフェイスの種類にある程度依存します。ギガビットまたは高速インタフェースを持つ現代のルータのため、個々のUPDATEが処理されてもよく、そのときの測定値をマイクロ秒以上の十何百もの解像度になされなければならないので、非常にミリ秒未満で再アドバタイズ。
Measurement units:
測定単位：
Time period.
期間。
Issues:
問題：
See also:
参照してください：
The BGP process(es) in a device might restart because operator intervention or a power failure caused a complete shutdown. In this case, a hard reset is needed. A peering session could be lost, for example, because of action on the part of the peer or a dropped TCP session. A device can reestablish its peers and re-advertise all relevant routes in a hard reset. However, if a peer is lost, but the BGP process has not failed, BGP has mechanisms for a "soft reset."
オペレータの介入や停電が完全にシャットダウンが発生したため、デバイスでのBGPプロセス（ES）が再起動する可能性があります。この場合、ハードリセットが必要とされています。ピアリングセッションは、ピアまたは削除TCPセッションの一部に対してアクションを、例えば、失われる可能性があります。デバイスはそのピアを再確立し、ハードリセットに関連するすべてのルートを再アドバタイズできます。ピアが失われているが、BGPプロセスが失敗していない場合は、BGPがためのメカニズムを持っている「ソフトリセット。」
Definition: An event that triggers a complete re-initialization of the routing tables on one or more BGP sessions, resulting in exchange of a full routing table on one or more links to the router.
定義：ルータへの1つまたは複数のリンク上の完全なルーティングテーブルの交換の結果として、一つ以上のBGPセッションのルーティングテーブルの完全な再初期化をトリガーするイベント。
Discussion:
討論：
Measurement units: N.A.
測定単位：N。A.
Issues:
問題：
See also:
参照してください：
Definition: A soft reset is performed on a per-neighbor basis; it does not clear the BGP session while re-establishing the peering relation and does not stop the flow of traffic.
定義：ソフトリセットは、ネイバー単位で行われます。ピアリング関係を再確立し、トラフィックの流れを停止しませんが、それは、BGPセッションをクリアしません。
Discussion: There are two methods of performing a soft reset: (1) graceful restart [GRMBGP], wherein the BGP device that has lost a peer continues to forward traffic for a period of time before tearing down the peer's routes and (2) soft refresh [RFC2918], wherein a BGP device can request a peer's Adj-RIB-Out.
ディスカッション：（1）グレースフルリスタートピアを失ったBGPデバイスは、ピアの経路を切断する前に、一定期間トラフィックを転送し続け、（2）ソフト請求[GRMBGP]：ソフトリセットを行う2つの方法があります。 BGPデバイスは、ピアの調整] - RIBアウトを要求することができる、請求リフレッシュ[RFC2918]。
Measurement units: N.A.
測定単位：N。A.
Issues:
問題：
See also:
参照してください：
Although this is not a complete list, all the items discussed below have a significant effect on BGP convergence. Not all of them can be addressed in the baseline measurements described in this document.
これは完全なリストではありませんが、以下で説明するすべての項目は、BGPコンバージェンスに大きな影響を与えます。それらのすべては、この文書で説明するベースライン測定で対処できるわけではありません。
These factors are conditions of testing external to the router Device Under Test (DUT).
これらの要因は、テスト（DUT）の下では、ルータ装置の外部テストの条件です。
As the number of peers increases, the BGP route selection algorithm is increasingly exercised. In addition, the phasing and frequency of updates from the various peers will have an increasingly marked effect on the convergence process on a router as the number of peers grows, depending on the quantity of updates generated by each additional peer. Increasing the number of peers also increases the processing workload for TCP and BGP keepalives.
ピアの数が増加するにつれて、BGP経路選択アルゴリズムはますます行使されます。ピアの数が大きくなるように加えて、様々なピアからアップデートの位相及び周波数は各追加のピアによって生成された更新の量に応じて、ルータ上の収束過程でますます顕著な効果を有するであろう。ピアの数を増やすことも、TCPおよびBGPキープアライブのための処理の負荷が増加します。
The number of routes per BGP peer is an obvious stressor to the convergence process. The number and relative proportion of multiple route instances and distinct routes being added or withdrawn by each peer will affect the convergence process, as will the mix of overlapping route instances and IGP routes.
BGPピア当たりの経路の数は、収束過程に明らかストレッサーです。れるように、複数のルートインスタンスと別個の経路の数および相対的比率は、収束プロセスに影響を与える各ピアによって追加または引き出される経路インスタンスとIGPルートの重複ミックス。
The number of routes and attributes being filtered and set as a fraction of the target route table size is another parameter that will affect BGP convergence.
経路の数と目標ルートテーブルサイズの割合として、濾過し、設定された属性はBGPの収束に影響を与える別のパラメータです。
The following are extreme examples:
以下の極端な例です：
o Minimal policy: receive all, send all.
O最小ポリシー：すべてを送信する、すべてを受け取ります。
o Extensive policy: up to 100% of the total routes have applicable policy.
O広範な政策：総ルートの最大100％が適用可能なポリシーを持っています。
There are interactions in the form of precedence, synchronization, duplication, and the addition of timers and route selection criteria. Ultimately, understanding BGP4 convergence must include an understanding of the interactions with both the IGPs and the protocols associated with the physical media, such as Ethernet, SONET, and DWDM.
優先順位、同期、複製、およびタイマー及び経路選択基準の添加の形で相互作用が存在します。最終的に、BGP4の収束を理解することのIGPと、イーサネット（登録商標）、SONET、およびDWDMなどの物理メディアに関連付けられたプロトコルの両方との相互作用の理解を含まなければなりません。
A router can use flap damping to respond to route flapping. Use of flap damping is not mandatory, so the decision to enable the feature, and to change parameters associated with it, can be considered a matter of routing policy.
ルータは、ルートフラッピングに対応するため、ダンピングフラップを使用することができます。ダンピングフラップの使用は必須ではありませんので、この機能を有効にすると、それに関連するパラメータを変更する決定は、ルーティングポリシーの問題と考えることができます。
The timers are defined by RFC 2439 [RFC2439] and discussed in RIPE-229 [RIPE229]. If this feature is in effect, it requires that the device keep additional state to carry out the damping, which can have a direct impact on the control plane due to increased processing. In addition, flap damping may delay the arrival of real changes in a route and affect convergence times.
タイマーは、RFC 2439 [RFC2439]で定義さRIPE229 [RIPE229]に記載されています。この機能が有効である場合、それは、装置が増加により処理する制御プレーンに直接影響を与えることができる減衰を行うために追加の状態を維持することを必要とします。また、フラップの減衰は、経路における実際の変化の到来を遅らせ、コンバージェンス時間に影響を与える可能性があります。
In theory, a BGP device could receive a set of updates that completely define the Internet and could remain in a steady state, only sending appropriate keepalives. In practice, the Internet will always be changing.
理論的には、BGPデバイスは、適切なキープアライブを送信し、完全にインターネットを定義し、定常状態で残っている可能性が一連の更新を受け取ることができます。実際には、インターネットは常に変化します。
Churn refers to control-plane processor activity caused by announcements received and sent by the router. It does not include keepalives and TCP processing.
チャーンが受信され、ルータによって送信されたアナウンスに起因するコントロールプレーンプロセッサ活性を指します。これは、キープアライブとTCP処理が含まれていません。
Churn is caused by both normal and pathological events. For example, if an interface of the local router goes down and the associated prefix is withdrawn, that withdrawal is a normal activity, although it contributes to churn. If the local device receives a withdrawal of a route it already advertises, or an announcement of a route it did not previously know, and it re-advertises this information, these are normal constituents of churn. Routine updates can range from single announcements or withdrawals, to announcements of an entire default-free table. The latter is completely reasonable as an initialization condition.
解約は、両方の正常および病的事象によって引き起こされます。それは解約に寄与するが、例えば、ローカルルータのインタフェースがダウンと関連する接頭辞が引き抜かれた場合、その離脱は、通常の活動です。ローカルデバイスは、それがすでにアドバタイズルートの撤退、またはそれ以前に知らなかったルートの発表を受けて、それがこの情報をアドバタイズし直す場合は、これらは、解約の通常の構成要素です。ルーチンの更新は、単一のアナウンスや引き出しから、全体のデフォルトのないテーブルの発表の範囲とすることができます。後者は、初期条件として完全に合理的です。
Flapping routes are a pathological contributor to churn, as is MED oscillation [RFC3345]. The goal of flap damping is to reduce the contribution of flapping to churn.
発振[RFC3345] MEDされるフラッピングルートが、解約する病理学的な寄稿者です。フラップダンピングの目標は、解約するフラッピングの寄与を低減することです。
The effect of churn on overall convergence depends on the processing power available to the control plane, and on whether the same processor(s) are used for forwarding and control.
全体的な収束に解約の効果は、制御プレーンで使用可能な処理能力に依存し、同じプロセッサ（単数または複数）は転送および制御のために使用されているかどうかについて。
8.2. Implementation-Specific and Other Factors Affecting BGP Convergence
8.2. BGPコンバージェンスに影響を与える実装固有およびその他の要因
These factors are conditions of testing internal to the Device Under Test (DUT), although they may affect its interactions with test devices.
これらの要因は、彼らが試験デバイスとの相互作用に影響を与えるかもしれないが、被試験デバイス（DUT）の内部テストの条件です。
The presence of actual traffic in the device may stress the control path in some fashion if both the offered load (due to data) and the control traffic (FIB updates and downloads as a consequence of flaps) are excessive. The addition of data traffic presents a more accurate reflection of realistic operating scenarios than would be presented if only control traffic were present.
（によるデータ）に提供された負荷と制御トラフィックの両方（フラップの結果としてFIBの更新とダウンロード）が過大である場合、デバイスの実際のトラフィックの存在は、いくつかの方法で制御パスを強調することができます。データトラフィックの添加は唯一の制御トラフィックが存在した場合は提示されるよりも、現実的な動作シナリオをより正確に反映を提示します。
Settings of delay and hold-down timers at the link level, as well as for BGP4, can introduce or ameliorate delays. As part of a test report, all relevant timers MUST be reported if they use non-default values.
遅延とホールドダウンタイマーリンクレベルでだけでなく、BGP4のための設定、導入したり遅延を改善することができます。彼らは非デフォルト値を使用する場合は、試験報告書の一環として、関連するすべてのタイマーは報告しなければなりません。
Because all BGP traffic and interactions occur over TCP, all relevant parameters characterizing the TCP sessions MUST be provided; e.g., slow start, max window size, maximum segment size, or timers.
すべてのBGPトラフィックとの相互作用は、TCP上で発生するため、TCPセッションを特徴づける、関連するすべてのパラメータが提供されなければなりません。例えば、スロースタート、最大ウィンドウサイズ、最大セグメントサイズ、またはタイマー。
Authentication in BGP is currently done using the TCP MD5 Signature Option [RFC2385]. The processing of the MD5 hash, particularly in devices with a large number of BGP peers and a large amount of update traffic, can have an impact on the control plane of the device.
BGPにおける認証は、現在TCP MD5署名オプション[RFC2385]を使用して行われます。 MD5ハッシュの処理は、特にBGPピアの数が多いと更新大量のトラフィックを持つデバイスでは、デバイスのコントロールプレーンに影響を与えることができます。
The document explicitly considers authentication as a performance-affecting feature, but does not consider the overall security of the routing system.
文書は、明示的にパフォーマンスに影響を与える機能として認証を考慮しますが、ルーティングシステムの全体的なセキュリティを考慮していません。
Thanks to Francis Ovenden for review and Abha Ahuja for encouragement. Much appreciation to Jeff Haas, Matt Richardson, and Shane Wright at Nexthop for comments and input. Debby Stopp and Nick Ambrose contributed the concept of route packing.
励ましのレビューのためのフランシスOvendenとアブハアフジャに感謝します。コメントや入力のためのネクストホップのジェフ・ハース、マット・リチャードソン、とシェーンライトに多くの感謝。デビーSTOPPとニック・アンブローズは、ルートパッキングの概念を貢献しました。
Alvaro Retana was a key member of the team that developed this document, and made significant technical contributions regarding route mixes. The team thanks him and regards him as a co-author in spirit.
アルバロRetanaは、この文書を開発したチームの主要メンバーだった、とルートミックスに関する重要な技術的貢献をしました。彼とは、精神共著者として彼に関してはチームのおかげ。
[RFC1771] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, March 1995.
[RFC1771] Rekhter、Y.、およびT.李、 "ボーダーゲートウェイプロトコル4（BGP-4）"、RFC 1771、1995年3月。
[RFC2439] Villamizar, C., Chandra, R., and R. Govindan, "BGP Route Flap Damping", RFC 2439, November 1998.
[RFC2439] Villamizar、C.、チャンドラ、R.、およびR.ゴヴィンダン、 "BGPルートフラップダンピング"、RFC 2439、1998年11月。
[RFC1812] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, June 1995.
[RFC1812]ベイカー、F.、RFC 1812、1995年6月 "IPバージョン4つのルータのための要件"。
[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.
[RIPE37]アフジャ、A.、Jahanian、F.、ボーズ、A.、およびC. Labovitz、 "遅延インターネットルーティングコンバージェンスの実験的研究"、ルーティングWGにRIPE37発表、2000年11月、<のhttp：// www.ripe.net/ripe/meetings/archive/熟し-37 /プレゼンテーション/ RIPE-37-収束/>。 【INSTBLTY] Labovitz、C.、マラン、G.、およびF. Jahanian、 "インターネットルーティングの起源不安定"、インフォコム99、1999年8月。
[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.
[RFC2622] Alaettinoglu、C.、ベイツ、T.、Gerich、E.、Karrenberg、D.、マイヤー、D.、テルプストラ、M.、およびC. Villamizar、 "ルーティングポリシー仕様言語（RPSL）"、RFC 2280 、1998年1月。
[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.
【RIPE229] Panigl、C.、シュミッツ、J.、スミス、P.、およびC. Vistoli、 "協調ルートフラップダンピングパラメータのRIPEルーティング-WG勧告、バージョン2"、RIPE 229、2001年10月。
[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, August 1998.
[RFC2385] Heffernanの、A.、 "TCP MD5署名オプションを使用してBGPセッションの保護"、RFC 2385、1998年8月。
[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.
[GLSSRY]ジュニパーネットワークス、 "のJunos（tm）のインターネットソフトウェアコンフィギュレーションガイドルーティングおよびルーティングプロトコル、リリース4.2"、のJunos 4.2および他のリリース、2000年9月、<http://www.juniper.net/techpubs/software/junos/ junos42 / swcmdref42 / HTML / glossary.html>。 [RFC2547]ローゼン、E.およびY. Rekhter、 "BGP / MPLS VPNの"、RFC 2547、1999年3月。
[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.
[PKTTRAIN]ジャイナ教、R.とS. Routhier、「パケットトレイン - 計測とコンピュータネットワークのトラフィックのための新モデル」コミュニケーション4で選択された領域に、IEEEジャーナル（6）、1986年9月。
[RFC2918] Chen, E., "Route Refresh Capability for BGP-4", RFC 2918, September 2000.
[RFC2918]チェン、E.、 "BGP-4のためのルートリフレッシュ機能"、RFC 2918、2000年9月。
[GRMBGP] Sangli, S., Rekhter, Y., Fernando, R., Scudder, J., and E. Chen, "Graceful Restart Mechanism for BGP", Work in Progress, June 2004.
【GRMBGP]サングリ、S.、Rekhter、Y.、フェルナンド、R.、スカダー、J.、およびE.チェン、 "BGPのためのグレースフルリスタート機構"、進歩、2004年6月に働いています。
[BGP-4] Chen, E. and Y. Rekhter, "Cooperative Route Filtering Capability for BGP-4", Work in Progress, March 2004.
[BGP-4]チェン、E.およびY. Rekhter、 "BGP-4のための共同ルートフィルタリング機能"、進歩、2004年3月での作業。
[RFC3654] Khosravi, H. and T. Anderson, "Requirements for Separation of IP Control and Forwarding", RFC 3654, November 2003.
[RFC3654] Khosravi、H.、およびT.アンダーソン、 "IP制御とフォワーディングの分離のための要件"、RFC 3654、2003年11月。
[RFC3345] McPherson, D., Gill, V., Walton, D., and A. Retana, "Border Gateway Protocol (BGP) Persistent Route Oscillation Condition", RFC 3345, August 2002.
[RFC3345]マクファーソン、D.、ギル、V.、ウォルトン、D.、およびA. Retana、 "ボーダーゲートウェイプロトコル（BGP）永続的なルート発振条件"、RFC 3345、2002年8月。
[RFC2858] Bates, T., Rekhter, Y., Chandra, R., and D. Katz, "Multiprotocol Extensions for BGP-4", RFC 2858, June 2000.
"BGP-4のためのマルチプロトコル拡張" [RFC2858]ベイツ、T.、Rekhter、Y.、チャンドラ、R.、およびD.カッツ、RFC 2858、2000年6月。
[RFC2545] Marques, P. and F. Dupont, "Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing", RFC 2545, March 1999.
[RFC2545]マルケス、P.およびF.デュポン、RFC 2545 "IPv6のドメイン間ルーティングのためのBGP-4マルチプロトコル拡張機能の使用"、1999年3月。
Authors' Addresses
著者のアドレス
Howard Berkowitz Gett Communications & CCI Training 5012 S. 25th St Arlington, VA 22206 USA
ハワード・バーコウィッツGETTコミュニケーション＆CCIトレーニング5012 S.第25回セントアーリントン、VA 22206 USA
Phone: +1 703 998-5819 Fax: +1 703 998-5058 EMail: hcb@gettcomm.com
電話：+1 703 998-5819ファックス：+1 703 998-5058 Eメール：hcb@gettcomm.com
Elwyn B. Davies Folly Consulting The Folly Soham Cambs, CB7 5AW UK
エルウィンB.デイヴィスフォリーコンサルティングザ・フォリーソーハムCambsの、CB7 5AW英国
Phone: +44 7889 488 335 EMail: elwynd@dial.pipex.com
電話：+44 7889 488 335 Eメール：elwynd@dial.pipex.com
Susan Hares Nexthop Technologies 825 Victors Way Ann Arbor, MI 48108 USA
スーザンノウサギネクスト・テクノロジーズ825ビクターズウェイアナーバー、MI 48108 USA
Phone: +1 734 222-1610 EMail: skh@nexthop.com
電話：+1 734 222-1610 Eメール：skh@nexthop.com
Padma Krishnaswamy SAIC 331 Newman Springs Road Red Bank, New Jersey 07701 USA
パドマKrishnaswamy SAIC 331ニューマンスプリングスの道レッドバンク、ニュージャージー州07701米国
EMail: padma.krishnaswamy@saic.com
メールアドレス：padma.krishnaswamy@saic.com
Marianne Lepp Consultant
マリアンヌアルダーコンサルタント
EMail: mlepp@lepp.com
メールアドレス：mlepp@lepp.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（2005）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。