RFC4098 日本語訳
4098 Terminology for Benchmarking BGP Device Convergence in theControl Plane. H. Berkowitz, E. Davies, Ed., S. Hares, P.Krishnaswamy, M. Lepp. June 2005. (Format: TXT=66845 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
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
コメントを求めるワーキンググループH.バーコウィッツ要求をネットワークでつないでください: 4098ゲットCommunicationsとCCIトレーニングカテゴリ: エド情報のE.デイヴィース、S.野兎のNexthop技術P.Krishnaswamy SAIC M.レップコンサルタント2005年6月に相談する愚かさ
Terminology for Benchmarking BGP Device Convergence
in the Control Plane
制御飛行機でのベンチマーキングBGPデバイス集合のための用語
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).
Copyright(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の両方に適切です。 それぞれのバージョンの説明に役立つ実例は関連しているところに含まれています。
Berkowitz, et al. Informational [Page 1] RFC 4098 Terminology for Benchmarking BGP June 2005
バーコウィッツ、他 ベンチマーキングBGP2005年6月のための情報[1ページ]のRFC4098用語
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
1. 序論…3 1.1. 概要と道路地図…4 1.2. 定義形式…5 2. 経路情報のコンポーネントと特性…5 2.1. (ネットワーク) 前に置きます。5 2.2. 接頭語の長さをネットワークでつないでください…6 2.3. 発送します。6 2.4. BGPルート…7 2.5. レベル可到達性情報(NLRI)をネットワークでつないでください…7 2.6. BGPはメッセージをアップデートします…8 3. ルート設定データ構造とルートカテゴリ…8 3.1. 情報を発送して、(あばら骨)を基礎づけてください…8 3.1.1. 中のAdjあばら骨とAdjあばら骨アウト…8 3.1.2. Loc-あばら骨…9 3.2. フィルタリングを前に置いてください…9 3.3. ルート設定方針…10 3.4. ルート設定方針Information基地…10 3.5. 情報を転送して、(空言)を基礎づけてください…11 3.6. BGPインスタンス…12 3.7. BGPデバイス…12 3.8. BGPセッション…13 3.9. 活発なBGPセッション…13 3.10. BGPはじっと見ます…13 3.11. BGP隣人…14 3.12. MinRouteAdvertisementInterval(MRAI)…14 3.13. MinASOriginationInterval(MAOI)…15 3.14. アクティブなルート…15 3.15. ユニークなルート…15 3.16. 非ユニークなルート…16 3.17. インスタンスを発送してください…16 4. ルータのルータかネットワークの構成分子…17 4.1. デフォルトルート、無デフォルトのテーブル、および完全なテーブル…17 4.1.1. デフォルトルート…17 4.1.2. 無デフォルトの経路指定テーブル…18 4.1.3. 完全な無デフォルトのテーブル…18 4.1.4. 無デフォルトのゾーン…19 4.1.5. 完全なプロバイダー内部のテーブル…19 4.2. BGP-話しルータのクラス…19 4.2.1. プロバイダー縁のルータ…20 4.2.2. 加入者縁のルータ…20 4.2.3. 相互プロバイダー境界ルータ…21 4.2.4. コアルータ…21 5. アップデートメッセージのセットの特殊化…22 5.1. パッキングを発送してください…22 5.2. 混合物を発送してください…23 5.3. 列車をアップデートしてください…24
Berkowitz, et al. Informational [Page 2] RFC 4098 Terminology for Benchmarking BGP June 2005
バーコウィッツ、他 ベンチマーキングBGP2005年6月のための情報[2ページ]のRFC4098用語
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
5.4. アップデートにおける偶発性は訓練されます…24 5.5. フラップを発送してください…25 6. 変化と集合を発送してください…25 6.1. 変化イベントを発送してください…25 6.2. 制御飛行機でのデバイス集合…27 7. BGP操作イベント…28 7.1. 困難なリセット…28 7.2. 柔らかいリセット…29 8. 集合プロセスのパフォーマンスに影響を与える要素…29 8.1. 一般は感激的なデバイス集合を因数分解します…29 8.1.1. 同輩の数…29 8.1.2. 1同輩あたりのルートの数…30 8.1.3. 方針処理/再構成…30 8.1.4. 他のプロトコルとの相互作用…30 8.1.5. 湿気をばたつかせてください…30 8.1.6. かきまぜてください…31 8.2. BGPに影響する実装特有の、そして、他の要素…31 8.2.1. トラフィックを進めます…31 8.2.2. タイマ…32 8.2.3. BGP輸送の基礎となるTCPパラメタ…32 8.2.4. 認証…32 9. セキュリティ問題…32 10. 承認…32 11. 参照…33 11.1. 標準の参照…33 11.2. 有益な参照…34
1. Introduction
1. 序論
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プロセスの集合性能を特徴付けることにおける使用のために用語を定義します。 (ドキュメントの残りでRFC1771と呼ばれた'ボーダ・ゲイトウェイ・プロトコル4(BGP-4)'[RFC1771]を見てください。) それは2ドキュメントのシリーズの最初の部分です。(そこでは、その後のドキュメントが関連テストと方法論を含むでしょう)。 この用語はIPv4とIPv6の両方に適切です。 それぞれのバージョンの説明に役立つ実例は関連しているところに含まれています。 しかしながら、このドキュメントはIPv4ネットワークにおけるBGP-4のために主として狙います。 IPv6はRFC2545[RFC2545]で説明されるようにMP-BGP[RFC2858]の使用を必要とするでしょうが、このドキュメントはBGP-4のこれらの拡大に特定の用語か問題を扱わないでしょう。 また、このドキュメントのための範囲の外にRFC2547[RFC2547]で説明されるようにVPNsをサポートするBGPの拡大に特定の用語と問題があります。
Berkowitz, et al. Informational [Page 3] RFC 4098 Terminology for Benchmarking BGP June 2005
バーコウィッツ、他 ベンチマーキングBGP2005年6月のための情報[3ページ]のRFC4098用語
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.
私たちは、テスト目的、すべての任意のパラメタSHOULDのためのそれがオフにされることに注意します。 テストが別の方法で指定しない場合、すべての可変パラメタSHOULDがそれらの既定の設定のそうです。
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.
その後のドキュメントはBGP-4と方針処理とコントロールでの同時のトラフィックとDevice Under Test(DUT)、および他の現実的な性能修飾語の中のデータ経路に集合測定のMultiprotocol Extensionsの存在の影響などの、より複雑な局面を探検するでしょう。 また、Interiorゲートウェイプロトコル(IGPs)の集合は別々のドキュメントで考えられるでしょう。
1.1. Overview and Road Map
1.1. 概要とロードマップ
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 集合を受けているネットワークかルータの構成分子の記述
Berkowitz, et al. Informational [Page 4] RFC 4098 Terminology for Benchmarking BGP June 2005
バーコウィッツ、他 ベンチマーキングBGP2005年6月のための情報[4ページ]のRFC4098用語
o Characterization of sets of update messages, types of route-change
events, as well as some events specific to BGP operation
o アップデートメッセージのセット、ルート変化イベントのタイプ、およびBGP操作に特定のいくつかのイベントの特殊化
o Descriptions of factors that impact the performance of convergence
processes
o 集合プロセスの性能に影響を与える要素の記述
1.2. Definition Format
1.2. 定義形式
The definition format is equivalent to that defined in 'Requirements for IP Version 4 Routers' [RFC1812], and is repeated here for convenience:
定義形式は、'IPバージョン4Routersのための要件'[RFC1812]で定義されたそれに同等であり、便宜のためにここで繰り返されます:
X.x Term to be defined (e.g., Latency).
定義されるべきX.x用語(例えば、Latency)。
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.
参照: 定義に関連している関連する用語のリストか今期の議論。
2. Components and Characteristics of Routing Information
2. 経路情報のコンポーネントと特性
2.1. (Network) Prefix
2.1. (ネットワーク) 接頭語
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、RFC1812の「階級のない間のドメインルート設定(CIDR)」を取る、)
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,
議論: CIDR文脈では、ネットワーク接頭語はIPアドレスのネットワーク要素です。 IPv4システムで、完全なアドレスのネットワーク要素は'ネットワーク一部'として知られています、そして、アドレスの残存部分は'ホスト部分'として知られています。 IPv6システムで
Berkowitz, et al. Informational [Page 5] RFC 4098 Terminology for Benchmarking BGP June 2005
バーコウィッツ、他 ベンチマーキングBGP2005年6月のための情報[5ページ]のRFC4098用語
the network component of a complete address is known as the
'subnet prefix', and the remaining part is known as the 'interface
identifier'.
完全なアドレスのネットワーク要素は'サブネット接頭語'として知られています、そして、残存部分は'インタフェース識別子'として知られています。
Measurement units: N.A.
測定単位: N.A。
Issues:
問題:
See also:
参照:
2.2. Network Prefix Length
2.2. ネットワーク接頭語の長さ
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に、.0/17が示すこのIPv4のネットワーク要素が扱う.128は幅17ビットです。 同様の記法はIPv6ネットワーク接頭語に使用されます。 例えば、2001:db8:719f:、:/48. アドレスのグループを参照すると、ネットワーク接頭語の長さはアドレスのグループを同値類として記述する手段としてしばしば使用されます。 例えば、'100/16のアドレス'はネットワーク接頭語の長さが16ビットである100のアドレスを参照します。
Measurement units:
Bits.
測定単位: ビット。
Issues:
問題:
See also:
Network Prefix.
参照: 接頭語をネットワークでつないでください。
2.3. Route
2.3. ルート
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-tuple<接頭語、nexthop[他のルーティングか非ルーティング・プロトコル属性]>です。 ルートは、終わらせないどんな終わりですがも、接頭語によって定義されるように次のステップでそれらの目的地に向かってパケットを持って行くはずである次の特定のホップに関して定義されます。 この用法で、ルートはルーティング・プロトコルから蒸留された目標の目的地の情報の原単位です。
Berkowitz, et al. Informational [Page 6] RFC 4098 Terminology for Benchmarking BGP June 2005
バーコウィッツ、他 ベンチマーキングBGP2005年6月のための情報[6ページ]のRFC4098用語
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ルート。
2.4. BGP Route
2.4. BGPルート
Definition:
A BGP route is an n-tuple <prefix, nexthop, ASpath [, other BGP
attributes]>.
定義: BGPルートはn-tuple<接頭語、nexthop、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."
議論: NexthopかAS経路などのBGP AttributesはRFC1771で定義されます、そして、彼らはルートを定義する資格を得るデータです。(そこでは、彼らがPath Attributesとして知られています)。 RFC1771から: 「このプロトコルの目的のために、ルートはその目的地への経路の属性と目的地を対にする情報のユニットと定義されます。」
Measurement units: N.A.
測定単位: N.A。
Issues:
問題:
See also:
Route, Prefix, Adj-RIB-In, Network Level Reachability Information
(NLRI)
参照: ルート、接頭語、中のAdjあばら骨は平らな可到達性情報をネットワークでつなぎます。(NLRI)
2.5. Network Level Reachability Information (NLRI)
2.5. 平らな可到達性情報をネットワークでつないでください。(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は経路属性によって説明された一般的なルートに沿ってパケットを発送できる(ネットワークにおけるこのポイントから)1セットの目的地をカプセル化します。
Berkowitz, et al. Informational [Page 7] RFC 4098 Terminology for Benchmarking BGP June 2005
バーコウィッツ、他 ベンチマーキングBGP2005年6月のための情報[7ページ]のRFC4098用語
Measurement units: N.A.
測定単位: N.A。
Issues:
問題:
See also:
Route Packing, Network Prefix, BGP Route, NLRI.
参照: NLRI、パッキング、BGPが発送するネットワーク接頭語を発送してください。
2.6. BGP UPDATE Message
2.6. BGPアップデートメッセージ
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分野の広告を含んでいます、ことによると複数の接頭語、および実行不可能なルートの複数の退出を含んでいて。 詳細に関してRFC1771を見てください。
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."
議論: RFC1771から: 「経路属性の可変長系列はあらゆるUPDATEに存在しています。」 「各経路、属性がa三重の<属性タイプ、属性の長さ、可変長の属性値>である、」
Measurement units: N.A.
測定単位: N.A。
See also:
参照:
3. Routing Data Structures and Route Categories
3. ルート設定データ構造とルートカテゴリ
3.1. Routing Information Base (RIB)
3.1. 経路情報基地(あばら骨)
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は論理的にセットされたaからまとめて成ります。(必ず物理的であるというわけではなく) 異なったデータベース。それのそれぞれが以下に列挙されます。 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.
このセットに含まれていたルートは数個の情報筋から潜在的に選択されました、ハードウェア状態、内部のルーティング・プロトコル、および外のルーティング・プロトコルを含んでいて。 RFC1812はオールソース文脈で関連しているルート選択評価基準の基本的なセットを含んでいます。 多くの実装が追加評価基準を課します。 一般的な実装特有の評価基準は異なったルーティング情報源に与えられた優先です。
3.1.1. Adj-RIB-In and Adj-RIB-Out
3.1.1. 中のAdjあばら骨とAdjあばら骨アウト
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と外のAdj-RIBは個々の同輩ルータの見解からのルーティング情報の「視点」です。 中のAdj-RIBは特定の同輩によってDUTに広告に掲載された情報を含んでいます。
Berkowitz, et al. Informational [Page 8] RFC 4098 Terminology for Benchmarking BGP June 2005
バーコウィッツ、他 ベンチマーキングBGP2005年6月のための情報[8ページ]のRFC4098用語
The Adj-RIB-Out contains the information the DUT will advertise to
the peer. See RFC 1771.
外のAdj-RIBはDUTが同輩に広告を出す情報を含んでいます。 RFC1771を見てください。
Discussion:
議論:
Issues:
問題:
Measurement units:
Number of route instances.
測定単位: ルートインスタンスの数。
See also:
Route, BGP Route, Route Instance, Loc-RIB, FIB.
参照: ルート、BGPルート、ルートインスタンス、Loc-あばら骨はたたきます。
3.1.2. Loc-RIB
3.1.2. Loc-あばら骨
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は様々なAdj-RIBsから選択される中で最も良いルートのセットを含んでいます、ローカルの方針と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.
議論: 様々なRIBsの中で暗示している分離は当然です。 必ず、これらのRIBsがどんな与えられた実装でも異なって別々の実体であるということになるというわけではありません。 考えられる必要があるルートのタイプは内部のBGP、外部のBGP、インタフェース、静電気、およびIGPルートを入れます。
Issues:
問題:
Measurement units:
Number of routes.
測定単位: ルートの数。
See also:
Route, BGP Route, Route Instance, Adj-RIB-In, Adj-RIB-Out, FIB.
参照: ルート、BGPルートはインスタンスを発送して、中のAdjあばら骨、Adjあばら骨アウトはたたかれます。
3.2. Prefix Filtering
3.2. 接頭語フィルタリング
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.
定義: 接頭語Filteringは、エントリーの候補としてルートを考慮からRIBにネットワーク接頭語のリストに対してBGP Routeのネットワーク接頭語を合わせることによって排除するためのテクニックです。
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
議論: 2つの接頭語で、リストからのどんなフィルタ接頭語にも、Route接頭語の長さが等しいか、またはフィルタ接頭語の長さと最も重要なビットより長いなら、BGP Routeは排除されます。
Berkowitz, et al. Informational [Page 9] RFC 4098 Terminology for Benchmarking BGP June 2005
バーコウィッツ、他 ベンチマーキングBGP2005年6月のための情報[9ページ]のRFC4098用語
match over the length of the filter prefix. See 'Cooperative
Route Filtering Capability for BGP-4' [BGP-4] for examples of
usage.
フィルタ接頭語の長さの上合ってください。 用法の例に関して'BGP-4のための協力的なRoute Filtering Capability'[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.
参照: 方針Information基地を発送して、方針を発送して、BGPルート、ネットワーク接頭語は接頭語の長さをネットワークでつなぎます。
3.3. Routing Policy
3.3. ルート設定方針
Definition:
Routing Policy is "the ability to define conditions for accepting,
rejecting, and modifying routes received in advertisements"
[GLSSRY].
定義: ルート設定Policyは「広告に受け取られたルートを受け入れて、拒絶して、変更するための状態を定義する能力」[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.
議論: RFC1771は、ホップごとのルーティングパラダイムの中に方針があるのをさらに抑制します。 政策はPrefix Filteringなどのフィルタを使用して、関連政策的措置であることが実施されます。 多くのASesがルート設定Policy Specification Language(RPSL)[RFC2622]を使用することで彼らの方針を定式化して、記録して、次に、BGPプロセスのためにRPSL仕様からそれらのルータで構成を自動的に生成します。
Measurement units:
Number of policies; length of policies.
測定単位: 方針の数。 方針の長さ。
Issues:
問題:
See also:
Routing Policy Information Base, Prefix Filtering.
参照: 方針Information基地を発送して、フィルタリングを前に置いてください。
3.4. Routing Policy Information Base
3.4. ルート設定方針Information基地
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
議論: 1771年のこれらのフェーズのRFC定義に関して以下のBGP選択プロセスのフェーズのすべての参照をします。 入って来る方針は、Phase2のためのメートル法を設定するためにBGP選択プロセスのPhase1で中のAdj-RIBルートに適用されます。
Berkowitz, et al. Informational [Page 10] RFC 4098 Terminology for Benchmarking BGP June 2005
バーコウィッツ、他 ベンチマーキングBGP2005年6月のための情報[10ページ]のRFC4098用語
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.
決定プロセス。 出発しているPoliciesは、ルート(接頭語と経路属性tuple)発表に特定の同輩に先行しながら、BGPプロセスのPhase3で外のAdj-RIBルートに適用されます。 Policy Information基地の中の方針には、マッチングと動作状態があります。 合わせる一般的な情報はルート接頭語、AS経路、共同体などを含んでいます。 マッチへの動作は、アップデートを下げて、それをLoc-RIBに通過しないか、または何らかの方法でアップデートを変更することであるかもしれません、地方の好み(入力での)かMED(出力での)を変えるのなどように、共同体を加えるか、または削除して、AS経路などで現在のASをprependingして 方針処理(路線図とフィルタ/アクセスリストに関する)の量は分配されたBGPアルゴリズムの集合時間と資産に影響を与えるでしょう。 方針処理の量はすべてのルートを受け入れて、複雑な方針に応じて接頭語のかなりの部分がフィルタ/アクセスリストによってフィルターにかけられている状態でそれらを送る簡単な方針と異なるかもしれません。
Measurement units:
Number and length of policies.
測定単位: 方針の数と長さ。
Issues:
問題:
See also:
参照:
3.5. Forwarding Information Base (FIB)
3.5. 推進Information基地(空言)
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."
定義: RIPE-37[RIPE37]のAppendix Bとの定義に従って: 「IPデータグラムを進めるのに必要な情報を含むテーブルはForwarding Information基地と呼ばれます。」 「最小限では、これはそれぞれの届いている送信先ネットワーク接頭語のためのインタフェース識別子と次のホップ情報を含んでいます。」
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)と異なっています。(それは、ルーティング同輩からすべてのルーティング情報を受け取るように主張します)。 それは、データ飛行機構造物であり、それぞれのパケットの推進に使用されます。 Forwarding Information基地はRIBから生成されます。 このドキュメントの目的のために、事実上、FIBは推進飛行機によって使用される、1パケットあたりの推進を決定にするRIBの部分集合です。 ほとんどの現在の実装には、ルータインタフェースあたりの完全で、非キャッシュされたFIBsがあります。 エントリーをFIBにダウンロードする前にすべての経路計算と集合が起こります。
Berkowitz, et al. Informational [Page 11] RFC 4098 Terminology for Benchmarking BGP June 2005
バーコウィッツ、他 ベンチマーキングBGP2005年6月のための情報[11ページ]のRFC4098用語
Measurement units: N.A.
測定単位: N.A。
Issues:
問題:
See also:
Route, RIB.
参照: ルート、あばら骨。
3.6. BGP Instance
3.6. BGPインスタンス
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の1つ以上のインスタンスを通常実行するでしょう。 ルータはただ一つのインスタンスを通常実行するでしょう。
Measurement units: N.A.
測定単位: N.A。
Issues:
問題:
See also:
参照:
3.7. BGP Device
3.7. BGPデバイス
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州のマシンを実行するのに責任がある1つ以上の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.
議論: 私たちは、一般的なケースとして「装置」を使用するのを選びました、発明される理解(例えば[GLSSRY])にされるのにもかかわらず、未来との取引にコントロール処理が推進[RFC2918]から別々であるかもしれないケース。 BGP装置は、伝統的なルータ、ルートサーバ、BGPの意識している交通ステアリング装置、または非推進ルート反射鏡であるかもしれません。 例えば、ルート反射鏡かサーバなどのBGP例は交通を決して進めません、それらに、測定値が無意味であるようにとても推進ベースです。
Measurement units: N.A.
測定単位: N.A。
Issues:
問題:
See also:
参照:
Berkowitz, et al. Informational [Page 12] RFC 4098 Terminology for Benchmarking BGP June 2005
バーコウィッツ、他 ベンチマーキングBGP2005年6月のための情報[12ページ]のRFC4098用語
3.8. BGP Session
3.8. BGPセッション
Definition:
A BGP session is a session between two BGP instances.
定義: BGPセッションは2つのBGP例の間のセッションです。
Discussion:
議論:
Measurement units: N.A.
測定単位: N.A。
Issues:
問題:
See also:
参照:
3.9. Active BGP Session
3.9. 活発なBGPセッション
Definition:
An active BGP session is one that is in the established state.
(See RFC 1771.)
定義: 活発なBGPセッションは設立された状態にあるものです。 (RFC1771を見てください。)
Discussion:
議論:
Measurement units: N.A.
測定単位: N.A。
Issues:
問題:
See also:
参照:
3.10. BGP Peer
3.10. BGP同輩
Definition:
A BGP peer is another BGP instance to which the DUT is in the
Established state. (See RFC 1771.)
定義: BGP同輩はDUTがEstablished状態にある別のBGP例です。 (RFC1771を見てください。)
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じっと見るセッションに関連していて、そのようなセッションのルータかテスターの活発なより多くのひとりがいるかもしれないことに注意する価値があります。 セッションがここに言及したじっと見ることは様々なクラスのBGPルータの間に存在するかもしれません(セクション4.2を見てください)。
Berkowitz, et al. Informational [Page 13] RFC 4098 Terminology for Benchmarking BGP June 2005
バーコウィッツ、他 ベンチマーキングBGP2005年6月のための情報[13ページ]のRFC4098用語
Measurement units:
Number of BGP peers.
測定単位: BGPの数はじっと見ます。
Issues:
問題:
See also:
参照:
3.11. BGP Neighbor
3.11. BGP隣人
Definition:
A BGP neighbor is a device that can be configured as a BGP peer.
定義: BGP隣人はBGP同輩として構成できる装置です。
Discussion:
議論:
Measurement units:
測定単位:
Issues:
問題:
See also:
参照:
3.12. MinRouteAdvertisementInterval (MRAI)
3.12. MinRouteAdvertisementInterval(MRAI)
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.
定義: (RFC1771から、言い換えられます) MRAIタイマはルートの広告の間で最小の時間を単一のBGP装置から特定の目的地(接頭語)に決定します。 タイマは1BGPあたり1個の装置ベースに設定されますが、タイマはプレ接頭語ベースで適用されます。
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例が10万以上のルートを管理するかもしれないなら、RFC1771は、必要であるタイマの数を制限するために1段階の最適化を考慮します。 MRAIは同じASのBGPスピーカーから受けられたルート、または、明白な退出に適用しません。 また、RFC1771は、無作為のジターがネットワークでBGP例の間の同期効果を避ける試みでMRAIに適用されることを勧めます。 本書では、私たちは、NLRIがDUTに広告に掲載される時からそれがDUTから広告に掲載される時まで測定することによって、ルーティング飛行機集合を定義します。 明確にMRAIによって挿入されたどんな遅れもこの測定に重要な影響を与えるでしょう。
Measurement units:
Seconds.
測定単位: 秒。
Berkowitz, et al. Informational [Page 14] RFC 4098 Terminology for Benchmarking BGP June 2005
バーコウィッツ、他 ベンチマーキングBGP2005年6月のための情報[14ページ]のRFC4098用語
Issues:
問題:
See also:
NLRI, BGP Route.
参照: NLRI、BGPルート。
3.13. MinASOriginationInterval (MAOI)
3.13. MinASOriginationInterval(MAOI)
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ルート。
3.14. Active Route
3.14. アクティブなルート
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.
参照: ろっ骨を付けます。
3.15. Unique Route
3.15. ユニークなルート
Definition:
A unique route is a prefix for which there is just one route
instance across all Adj-Ribs-In.
定義: ユニークなルートはちょうど1つのルート例が中のすべてのAdjあばら骨のむこうにある接頭語です。
Berkowitz, et al. Informational [Page 15] RFC 4098 Terminology for Benchmarking BGP June 2005
バーコウィッツ、他 ベンチマーキングBGP2005年6月のための情報[15ページ]のRFC4098用語
Discussion:
議論:
Measurement units: N.A.
測定単位: N.A。
Issues:
問題:
See also:
Route, Route Instance.
参照: ルート、ルート例。
3.16. Non-Unique Route
3.16. 非ユニークなルート
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.
定義: 非ユニークなルートは中の1Adj-RIBを含むセットに他の少なくとも1つのルートがある接頭語です。
Discussion:
議論:
Measurement units: N.A.
測定単位: N.A。
Issues:
問題:
See also:
Route, Route Instance, Unique Active Route.
参照: ルート、ルート例、ユニークなアクティブなルート。
3.17. Route Instance
3.17. ルート例
Definition:
A route instance is one of several possible occurrences of a route
for a particular prefix.
定義: ルート例は特定の接頭語のためのルートのいくつかの可能な発生の1つです。
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ベースの中のルート例の数は、機能に基づいてルータによって実行されるために異なるでしょう。 無デフォルトのゾーン(セクション4.1.4を見る)に位置する相互プロバイダー境界ルータはおそらくネットワークのエンドユーザの、より近くに位置したプロバイダー縁のルータより多くのルート例を受けるでしょう。
Berkowitz, et al. Informational [Page 16] RFC 4098 Terminology for Benchmarking BGP June 2005
バーコウィッツ、他 ベンチマーキングBGP2005年6月のための情報[16ページ]のRFC4098用語
See also:
参照:
4. Constituent Elements of a Router or Network of Routers
4. ルータのルータかネットワークの構成分子
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.
定義のこのリストに多くの用語を含んでいるのは元々、前の規格か書類で説明されました。 それらは自己の適切のためにここでこの議論に含められています。 関連しているところで、参照はこれらのソースに作られています。 必要な概念に関して過剰定義なしで完全にこのリストを保つのを努力をしました。
4.1. Default Route, Default-Free Table, and Full Table
4.1. デフォルトルート、無デフォルトのテーブル、および完全なテーブル
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倍のルートであるかもしれないことに注意してください。
4.1.1. Default Route
4.1.1. デフォルトルート
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.
定義: デフォルトルートはどんな送付先アドレスにも合うことができます。 ルータに特定のパケットの送付先アドレスのための、より特定のルートがないなら、デフォルトルートエントリーにおける次のホップにこのパケットを送ります、Forwarding Tableであれば(推進情報の基地、または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.
参照: 無デフォルトの経路指定テーブル、ルートは例を発送します。
Berkowitz, et al. Informational [Page 17] RFC 4098 Terminology for Benchmarking BGP June 2005
バーコウィッツ、他 ベンチマーキングBGP2005年6月のための情報[17ページ]のRFC4098用語
4.1.2. Default-Free Routing Table
4.1.2. 無デフォルトの経路指定テーブル
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.
議論: 用語がインターネットのコアか最高層のルータがデフォルトルートによって構成されないという概念から発する、(記法、コネIPv4 0.0.0の.0/0とコネ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.
参照: 完全な無デフォルトのテーブル、デフォルトルート。
4.1.3. Full Default-Free Table
4.1.3. 完全な無デフォルトのテーブル
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
問題: 完全な無デフォルトの経路指定テーブルはすべての届いているユニキャストアドレスの組合と同じではありません。 テーブルは絶対にそうしません。
Berkowitz, et al. Informational [Page 18] RFC 4098 Terminology for Benchmarking BGP June 2005
バーコウィッツ、他 ベンチマーキングBGP2005年6月のための情報[18ページ]のRFC4098用語
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.
参照: ルート、ルート例、デフォルトルート。
4.1.4. Default-Free Zone
4.1.4. 無デフォルトのゾーン
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.
参照: デフォルトルート。
4.1.5. Full Provider-Internal Table
4.1.5. 完全なプロバイダー内部のテーブル
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.
参照: ルート、ルート例、デフォルトルート。
4.2. Classes of BGP-Speaking Routers
4.2. BGP-話しルータのクラス
A given router may perform more than one of the following functions, based on its logical location in the network.
与えられたルータはネットワークにおける論理的な位置に基づいて以下の機能の1つ以上を実行するかもしれません。
Berkowitz, et al. Informational [Page 19] RFC 4098 Terminology for Benchmarking BGP June 2005
バーコウィッツ、他 ベンチマーキングBGP2005年6月のための情報[19ページ]のRFC4098用語
4.2.1. Provider Edge Router
4.2.1. プロバイダー縁のルータ
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.
議論: このルータを通過する交通は、運命づけられているか、または非隣接している自律システムから発するかもしれません。Provider Edge Routerで使用されるMED値は非隣接している自律システムで特に、目に見えないでしょう。そのようなルータは、いつもeBGPを話して、iBGPを話すかもしれません。
Measurement units:
測定単位:
Issues:
問題:
See also:
参照:
4.2.2. Subscriber Edge Router
4.2.2. 加入者縁のルータ
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(s)に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とそのエンドユーザ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.
問題: 厳しいというよりむしろ企業境界ルータ(ほとんどのSubscriber Edge Routersが何であるかということである)のこの定義は実用的です。 多くの企業がそれら自身のルートの広告を出して、デフォルトだけか部分的なルートのどちらかを受け入れるBGPスピーカーを必要とするかもしれないのが現実に注意を向けることになっています。 そのような場合、彼らは、より小さい制御飛行機プロセッサが彼らの需要を満たすかどうか確認するのに部分的な経路指定テーブルを使用するベンチマークに興味を持つかもしれません。
See also:
参照:
Berkowitz, et al. Informational [Page 20] RFC 4098 Terminology for Benchmarking BGP June 2005
バーコウィッツ、他 ベンチマーキングBGP2005年6月のための情報[20ページ]のRFC4098用語
4.2.3. Inter-provider Border Router
4.2.3. 相互プロバイダー境界ルータ
Definition:
An inter-provider border router is a BGP speaking router that
maintains BGP sessions with other BGP speaking routers in other
providers' ASes.
定義: 相互プロバイダー境界ルータは他のプロバイダーのASesでルータを話す他の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があるどんなダイレクト接続性も持っていない別のASのために起こるか、または運命づけられるかもしれません。 そのようなルータは、いつもeBGPを話して、iBGPを話すかもしれません。
Measurement units:
測定単位:
Issues:
問題:
See also:
参照:
4.2.4. Core Router
4.2.4. コアルータ
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.
問題: この定義で、eBGPルータであるDUTsはコアルータではありません。
See also:
参照:
Berkowitz, et al. Informational [Page 21] RFC 4098 Terminology for Benchmarking BGP June 2005
バーコウィッツ、他 ベンチマーキングBGP2005年6月のための情報[21ページ]のRFC4098用語
5. Characterization of Sets of Update Messages
5. アップデートメッセージのセットの特殊化
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.
これはDUT走行BGPに入力されるように予想される検査刺激の種類の形式化です。 このデータはよく特徴付けられて、注文されて、調節されたセットの手作りのBGP UPDATEパケットであるかもしれません。 また、ちょうどそれはライブルータから捕らえられた1セットの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.
ルート混合物とアップデート列車の特殊化は研究の空地です。 この仕事のための興味がある特定の質問はUPDATEsの現実的な系列と彼らのコンテンツを反映するライブ跡から似せられるか、または乗られた適当なアップデート列車の識別です。
5.1. Route Packing
5.1. ルートパッキング
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.
定義: ルートパッキングはアップデート(追加か変更)として、または、独身のルート設定プロトコルUPDATE Messageか、退出として対応されたルート接頭語の数です。
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.
議論: 一般に、ルーティング・プロトコルアップデートは1つ以上の接頭語を含むかもしれません。 BGPでは、独身のUPDATEは複数のネットワーク接頭語の2セットを含むかもしれません: 同じ属性(NLRI)がある1セットの追加とアップデートと1セットの引き下がるべき実行不可能なルート。
Measurement units:
測定単位:
Number of prefixes.
接頭語の数。
Issues:
問題:
See also:
Route, BGP Route, Route Instance, Update Train, NLRI.
参照: ルート、BGPルート、ルート例は列車、NLRIをアップデートします。
Berkowitz, et al. Informational [Page 22] RFC 4098 Terminology for Benchmarking BGP June 2005
バーコウィッツ、他 ベンチマーキングBGP2005年6月のための情報[22ページ]のRFC4098用語
5.2. Route Mixture
5.2. ルート混合物
Definition:
A route mixture is the demographics of a set of routes.
定義: ルート混合物は1セットのルートの人口統計です。
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
* 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、あばら骨。
Berkowitz, et al. Informational [Page 23] RFC 4098 Terminology for Benchmarking BGP June 2005
バーコウィッツ、他 ベンチマーキングBGP2005年6月のための情報[23ページ]のRFC4098用語
5.3. Update Train
5.3. アップデート列車
Definition:
An update train is a set of Routing Protocol UPDATE messages sent
by a router to a BGP peer.
定義: アップデート列車はルータによってBGP同輩に送られた1セットのルート設定プロトコル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.
議論: 多くのものでUPDATEsの到着パターンに影響を及ぼすことができます、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、MAOIを発送してください。
5.4. Randomness in Update Trains
5.4. アップデート列車の偶発性
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
* NLRIs
* updates and withdrawals
* アップデートと退出
* prefixes
* 接頭語
* inter-arrival times of the UPDATEs and possibly across other
variables.
* ことによるとUPDATEsと他の変数の向こう側の相互到着時間。
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.
これはUPDATEパケットには任意のコンテンツがあるかもしれないネットワークの予測できない非同期的性質をシミュレートするつもりです、そして、無作為に渡してください。回。
Berkowitz, et al. Informational [Page 24] RFC 4098 Terminology for Benchmarking BGP June 2005
バーコウィッツ、他 ベンチマーキングBGP2005年6月のための情報[24ページ]のRFC4098用語
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つの業者の実現を支持するのを避けることができるくらいデータセットがランダマイズされるのは、重要です。 明確に、特定の業者のデータベースにおける、ルートの内部の組織を支持するために接頭語の分配を構造化できました。 これは避けられることになっています。
5.5. Route Flap
5.5. ルートフラップ
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.
議論: アップデート列車の特別で病理学的なケースであるとルートのばたつくことを考えることができます。 過度に急速であると考えられるかもしれないことに関する実用的な解釈はRIPE229です[RIPE229]。(そのRIPEはフラップをじめじめとしたパラメタに関する現在のガイドラインを含みます)。
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で特定のFlap出来事を見つけることができます。 テストにおけるSHOULDが混合物を使用するベンチマーカーの異なったルート変化イベント。
See also:
Route Change Events, Flap Damping, Packet Train
参照: ルート変化イベント、フラップ湿気、パケット列車
6. Route Changes and Convergence
6. ルート変化と集合
The following two definitions are central to the benchmarking of external routing convergence and are therefore singled out for more extensive discussion.
以下の2つの定義が、外部のルーティング集合のベンチマーキングに主要であり、したがって、より大規模な議論のために選び抜かれます。
6.1. Route Change Events
6.1. ルート変化イベント
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.
操作上のネットワークで見られたルーティング情報変化を特徴付ける分類学はRIPE-37[RIPE37]とLabovitz他[INSTBLTY]で提案されます。 これらの論文はネットワークの振舞いの分析の間にBGPのプロトコル中心の出来事とイベント系列について説明します。 2個の書類の用語は何らかのオーバラップがある同様の、しかし、わずかに異なった振舞いを分類します。 可能であるところで定義でテストを分類するためにこれらの分類学を適用したいと思います、これらのテストが実際のネットワークで起こる現象に結びつかなければならないので。 私たちは、この目的に必要に応じてこの用語を自分達に利用して、与えるかもしれません。
Berkowitz, et al. Informational [Page 25] RFC 4098 Terminology for Benchmarking BGP June 2005
バーコウィッツ、他 ベンチマーキングBGP2005年6月のための情報[25ページ]のRFC4098用語
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.
ルートのそれを別のルートに取り替えることによってそれとなく変えるか、または新しいルートの導入は退出で明らかにあとに続くことができます。 どちらかの場合では、変化は、実際の変化、変化がない、または写しであるかもしれません。 個々の分類可能ルート変化イベントの記法と定義を[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. 雄羊(TDx): Test Device xによってDUTに広告に掲載されたルート
2. Tdown(TDx): Route being withdrawn by Device x
2. Tdown(TDx): Device 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. 雄羊(1、TDx)手段Device xは1つのルートを送ります。
2. Tup(S,TDx) means Device x sends a train, S, of routes
2. 雄羊(S、TDx)手段Device xは列車、ルートのSを送ります。
3. Tup(DFT,TDx) means Device x sends an approximation of a full
default-free table.
3. 雄羊(DFT、TDx)手段Device xは完全な無デフォルトのテーブルの近似を送ります。
Berkowitz, et al. Informational [Page 26] RFC 4098 Terminology for Benchmarking BGP June 2005
バーコウィッツ、他 ベンチマーキングBGP2005年6月のための情報[26ページ]のRFC4098用語
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:
「より良い」ルートを選択するための基本的な評価基準はRFC1771、ルータ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より悪い経路の広告を出してください。
6.2. Device Convergence in the Control Plane
6.2. 制御飛行機での装置集合
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,
* 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
それは私たちがここにと方法論ドキュメントで説明する後者です。 私たちがルーティング・プロトコル性能(唯一の全体的に見て装置の一部である)をベンチマークに試みているので、この定義がいずれも除くことを意図します(できるだけ遠くに)。
Berkowitz, et al. Informational [Page 27] RFC 4098 Terminology for Benchmarking BGP June 2005
バーコウィッツ、他 ベンチマーキングBGP2005年6月のための情報[27ページ]のRFC4098用語
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を処理して、たいへん1ミリセカンド未満に再広告を出すかもしれないので、時間測定を数百の解決にマイクロセカンドか10より良いまでしなければなりません。
Measurement units:
測定単位:
Time period.
期間。
Issues:
問題:
See also:
参照:
7. BGP Operation Events
7. BGP操作出来事
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には、「柔らかいリセット」のためのメカニズムがあります。
7.1. Hard Reset
7.1. 困難なリセット
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セッションの経路指定テーブルの完全な再初期化の引き金となる出来事、1以上における完全な経路指定テーブルの交換をもたらすのはルータにリンクされます。
Discussion:
議論:
Measurement units: N.A.
測定単位: N.A。
Issues:
問題:
Berkowitz, et al. Informational [Page 28] RFC 4098 Terminology for Benchmarking BGP June 2005
バーコウィッツ、他 ベンチマーキングBGP2005年6月のための情報[28ページ]のRFC4098用語
See also:
参照:
7.2. Soft Reset
7.2. 柔らかいリセット
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.
定義: 柔らかいリセットは1隣人ベースに実行されます。 それは、じっと見る関係を復職させている間の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.
議論: 柔らかいリセットを実行する2つの方法があります: (1) 優雅な再開[GRMBGP]、同輩を失ったBGP装置が、同輩のルートと(2)を取りこわす前にしばらく柔らかい状態で交通を進め続けているところで[RFC2918]をリフレッシュしてください、BGP装置が外の同輩のAdj-RIBを要求できるところで。
Measurement units: N.A.
測定単位: N.A。
Issues:
問題:
See also:
参照:
8. Factors That Impact the Performance of the Convergence Process
8. 集合の過程のパフォーマンスに影響を与える要素
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集合に重要な影響を与えます。 本書では説明された基線測定値にそれらのすべてを記述できるというわけではありません。
8.1. General Factors Affecting Device Convergence
8.1. 装置集合に影響する一般要素
These factors are conditions of testing external to the router Device Under Test (DUT).
これらの要素はルータDevice Under Test(DUT)への外部のテストの状態です。
8.1.1. Number of Peers
8.1.1. 同輩の数
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 keepalivesのために処理ワークロードを増加させます。
Berkowitz, et al. Informational [Page 29] RFC 4098 Terminology for Benchmarking BGP June 2005
バーコウィッツ、他 ベンチマーキングBGP2005年6月のための情報[29ページ]のRFC4098用語
8.1.2. Number of Routes per Peer
8.1.2. 1同輩あたりのルートの数
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ルートを重ね合わせるミックスのように。
8.1.3. Policy Processing/Reconfiguration
8.1.3. 方針処理/再構成
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%には、適切な方針があります。
8.1.4. Interactions with Other Protocols
8.1.4. 他のプロトコルとの相互作用
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集合を理解していると、両方のIGPsとの相互作用と物理的なメディアに関連しているプロトコルの理解は包含しなければなりません、イーサネットや、Sonetや、DWDMなどのように。
8.1.5. Flap Damping
8.1.5. フラップ湿気
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.
タイマについて、RFC2439[RFC2439]によって定義されて、RIPE229[RIPE229]で議論します。 この特徴が有効であるなら、湿気を行うのが、装置が追加状態を維持するのを必要とします。(湿気は増加する処理のため制御飛行機の上に直接的な衝撃を持つことができます)。 さらに、フラップ湿気は、ルートの本当の変化の到着を遅らせて、集合時間に影響するかもしれません。
Berkowitz, et al. Informational [Page 30] RFC 4098 Terminology for Benchmarking BGP June 2005
バーコウィッツ、他 ベンチマーキングBGP2005年6月のための情報[30ページ]のRFC4098用語
8.1.6. Churn
8.1.6. 攪乳器
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装置は、インターネットを完全に定義する1セットのアップデートを受けることができて、定常状態に残ることができました、適切なkeepalivesを送るだけであって。 実際には、インターネットはいつも変化するでしょう。
Churn refers to control-plane processor activity caused by announcements received and sent by the router. It does not include keepalives and TCP processing.
攪乳器はルータによって受けられて、送られた発表で引き起こされた制御飛行機プロセッサ活動について言及します。 それはkeepalivesと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.
ばたつくルートはMED振動[RFC3345]のようにかきまぜる病理学的な貢献者です。 フラップ湿気の目標はかきまぜるためにばたつくことの貢献を抑えることです。
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.
これらの要素はDevice Under Test(DUT)への内部のテストの状態です、試験器具との相互作用に影響するかもしれませんが。
8.2.1. Forwarded Traffic
8.2.1. 進められた交通
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はフラップの結果としてアップデートして、ダウンロードする)の両方が過度であるなら、装置の実際の交通の存在は何らかのファッションでコントロール経路を強調するかもしれません。 コントロール交通だけが存在しているなら提示されるより交通が現実的な操作シナリオのさらに正確な反映を提示するデータの添加。
Berkowitz, et al. Informational [Page 31] RFC 4098 Terminology for Benchmarking BGP June 2005
バーコウィッツ、他 ベンチマーキングBGP2005年6月のための情報[31ページ]のRFC4098用語
8.2.2. Timers
8.2.2. タイマ
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抑制タイマは、遅れを導入するか、または改善できます。 試験報告書の一部として、非デフォルト値を使用するなら、すべての関連タイマを報告しなければなりません。
8.2.3. TCP Parameters Underlying BGP Transport
8.2.3. BGP輸送の基礎となるTCPパラメタ
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セッションを特徴付けるすべての関連パラメタを提供しなければなりません。 例えば、始め、最大ウィンドウサイズ、最大のセグメントサイズ、またはタイマを遅くしてください。
8.2.4. Authentication
8.2.4. 認証
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 Signature Option[RFC2385]を使用し終わっています。 特に多くのBGP同輩と多量のアップデート交通を伴う装置でのMD5細切れ肉料理の処理は装置の制御飛行機に影響を与えることができます。
9. Security Considerations
9. セキュリティ問題
The document explicitly considers authentication as a performance- affecting feature, but does not consider the overall security of the routing system.
ドキュメントは、認証が性能の感激的な機能であると明らかにみなしますが、ルーティングシステムの総合的なセキュリティを考えません。
10. Acknowledgements
10. 承認
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.
レビューとアブハーAhujaを奨励のためにフランシスOvendenをありがとうございます。 コメントと入力のためのNexthopのJeff Haas、マット・リチャードソン、およびシェーン・ライトに対する多くの感謝。 デビー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.
アルバロ・レタナはルートミックスに関してこのドキュメントを開発して、重要な技術的な貢献をしたチームの主要なメンバーでした。 彼に感謝します、そして、チームは精神で彼を共著者と見なします。
Berkowitz, et al. Informational [Page 32] RFC 4098 Terminology for Benchmarking BGP June 2005
バーコウィッツ、他 ベンチマーキングBGP2005年6月のための情報[32ページ]のRFC4098用語
11. References
11. 参照
11.1. Normative References
11.1. 引用規格
[RFC1771] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4
(BGP-4)", RFC 1771, March 1995.
1995年の[RFC1771]RekhterとY.とT.李、「ボーダ・ゲイトウェイ・プロトコル4(BGP-4)」、RFC1771行進。
[RFC2439] Villamizar, C., Chandra, R., and R. Govindan, "BGP Route
Flap Damping", RFC 2439, November 1998.
[RFC2439] VillamizarとC.とチャンドラ、R.とR.Govindan、「BGPルートフラップ湿気」、RFC2439、1998年11月。
[RFC1812] Baker, F., "Requirements for IP Version 4 Routers", RFC
1812, June 1995.
[RFC1812] ベイカー、F.、「IPバージョン4ルータのための要件」、RFC1812、1995年6月。
[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] ルート設定WG熟している37熟しているミーティング/アーカイブ/37/プレゼンテーション/集合/>2000年11月<http://www.ripe.net/熟している/[INSTBLTY]LabovitzとC.とマラン、G.とF.Jahanian、「インターネットルート設定の不安定性の起源」Infocom99(1999年8月)へのAhuja、A.、Jahanian、F.、ボーズ、A.、およびC.Labovitz、「遅れたインターネットルート設定集合の実証研究」、熟している37プレゼンテーション。
[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)」、RFC2280(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 Recommendationは湿気パラメタをばたつかせます、バージョン2インチ、RIPE229、2001年10月。」
[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP
MD5 Signature Option", RFC 2385, August 1998.
[RFC2385] ヘファーナン、A.、「TCP MD5 Signature Optionを通したBGPセッションズの保護」、RFC2385、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]杜松Networks、「2547年のJunos(tm)インターネットソフトウェアのリリースの2000年9月(<http://www.juniper.net/techpubs/ソフトウェア/junos/junos42/swcmdref42/html/glossary.html>)の構成ガイドルート設定とルーティング・プロトコルと4.2インチとJunos4.2と他のリリースと[RFC2547]ローゼンとE.とY.Rekhter、「BGP/MPLS VPNs」RFC、1999年3月。」
Berkowitz, et al. Informational [Page 33] RFC 4098 Terminology for Benchmarking BGP June 2005
バーコウィッツ、他 ベンチマーキングBGP2005年6月のための情報[33ページ]のRFC4098用語
[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、「パケットは訓練されます--測定とコンピュータネットワーク交通への新しいモデル」、Communication 4(6)のSelected Areasの上のIEEE Journal、1986年9月。
11.2. Informative References
11.2. 有益な参照
[RFC2918] Chen, E., "Route Refresh Capability for BGP-4", RFC
2918, September 2000.
[RFC2918]チェン、E.、「ルートは2000年9月にBGP-4インチ、RFC2918のために能力をリフレッシュします」。
[GRMBGP] Sangli, S., Rekhter, Y., Fernando, R., Scudder, J., and
E. Chen, "Graceful Restart Mechanism for BGP", Work in
Progress, June 2004.
[GRMBGP]サーングリ、S.、Y.とフェルナンドとR.とScudder、J.とE.チェン、「BGPのための優雅な再開メカニズム」というRekhterは進行中(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は「2004年3月にBGP-4インチ、処理中の作業のためにフィルタリング能力を協力して発送します」。
[RFC3654] Khosravi, H. and T. Anderson, "Requirements for
Separation of IP Control and Forwarding", RFC 3654,
November 2003.
[RFC3654] KhosraviとH.とT.アンダーソン、「IPコントロールと推進の分離のための要件」、RFC3654、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.レタナは「ゲートウェイのプロトコルの(BGP)しつこいルート振動状態に接しています」、RFC3345、2002年8月。
[RFC2858] Bates, T., Rekhter, Y., Chandra, R., and D. Katz,
"Multiprotocol Extensions for BGP-4", RFC 2858, June
2000.
[RFC2858] ベイツ、T.、Rekhter、Y.、チャンドラ、R.、およびD.キャッツ、「BGP-4インチのためのMultiprotocol拡張子、RFC2858、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.デュポン、「BGP-4 Multiprotocol拡張子のIPv6相互ドメインルート設定の使用」、RFC2545、1999年3月。
Berkowitz, et al. Informational [Page 34] RFC 4098 Terminology for Benchmarking BGP June 2005
バーコウィッツ、他 ベンチマーキングBGP2005年6月のための情報[34ページ]のRFC4098用語
Authors' Addresses
作者のアドレス
Howard Berkowitz Gett Communications & CCI Training 5012 S. 25th St Arlington, VA 22206 USA
5012秒間第25Stヴァージニア22206アーリントン(米国)を訓練するハワード・バーコウィッツ・ゲットコミュニケーションとCCI
Phone: +1 703 998-5819 Fax: +1 703 998-5058 EMail: hcb@gettcomm.com
以下に電話をしてください。 +1 703 998-5819Fax: +1 703 998-5058 メールしてください: hcb@gettcomm.com
Elwyn B. Davies Folly Consulting The Folly Soham Cambs, CB7 5AW UK
愚かさSoham Cambs、CB7 5AWイギリスに相談するElwyn B.デイヴィースの愚かさ
Phone: +44 7889 488 335 EMail: elwynd@dial.pipex.com
以下に電話をしてください。 +44 7889 488 335はメールされます: elwynd@dial.pipex.com
Susan Hares Nexthop Technologies 825 Victors Way Ann Arbor, MI 48108 USA
スーザン野兎のNexthop、MI48108アナーバー(米国)の技術825勝者道
Phone: +1 734 222-1610 EMail: skh@nexthop.com
以下に電話をしてください。 +1 734 222-1610 メールしてください: skh@nexthop.com
Padma Krishnaswamy SAIC 331 Newman Springs Road Red Bank, New Jersey 07701 USA
Padma Krishnaswamy SAIC331ニューマン春の道路赤の銀行、ニュージャージー07701米国
EMail: padma.krishnaswamy@saic.com
メール: padma.krishnaswamy@saic.com
Marianne Lepp Consultant
マリアンエレップコンサルタント
EMail: mlepp@lepp.com
メール: mlepp@lepp.com
Berkowitz, et al. Informational [Page 35] RFC 4098 Terminology for Benchmarking BGP June 2005
バーコウィッツ、他 ベンチマーキングBGP2005年6月のための情報[35ページ]のRFC4098用語
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2005).
Copyright(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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機能のための基金は現在、インターネット協会によって提供されます。
Berkowitz, et al. Informational [Page 36]
バーコウィッツ、他 情報[36ページ]
一覧
スポンサーリンク
