RFC1772 日本語訳
1772 Application of the Border Gateway Protocol in the Internet. Y.Rekhter, P. Gross. March 1995. (Format: TXT=43916 bytes) (Obsoletes RFC1655) (Status: DRAFT STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group Y. Rekhter
Request for Comments: 1772 T.J. Watson Research Center, IBM Corp.
Obsoletes: 1655 P. Gross
Category: Standards Track MCI
Editors
March 1995
Rekhterがコメントのために要求するワーキンググループY.をネットワークでつないでください: 1772 T.J.ワトソン研究所、IBM社は以下を時代遅れにします。 1655年のP.の総計のカテゴリ: 1995年の標準化過程MCIエディターズ行進
Application of the Border Gateway Protocol in the Internet
インターネットでのボーダ・ゲイトウェイ・プロトコルの応用
Status of this Memo
このMemoの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Abstract
要約
This document, together with its companion document, "A Border Gateway Protocol 4 (BGP-4)", define an inter-autonomous system routing protocol for the Internet. "A Border Gateway Protocol 4 (BGP-4)" defines the BGP protocol specification, and this document describes the usage of the BGP in the Internet.
このドキュメント、仲間ドキュメントと共に、「ボーダ・ゲイトウェイ・プロトコル4(BGP-4)」は相互自律システムルーティング・プロトコルをインターネットと定義します。 「ボーダ・ゲイトウェイ・プロトコル4(BGP-4)」はBGPプロトコル仕様を定義します、そして、このドキュメントはインターネットでBGPの使用法を説明します。
Information about the progress of BGP can be monitored and/or reported on the BGP mailing list (bgp@ans.net).
BGPメーリングリスト( bgp@ans.net )に関してBGPの進歩に関する情報をモニターされる、そして/または、報告できます。
Acknowledgements
承認
This document was originally published as RFC 1164 in June 1990, jointly authored by Jeffrey C. Honig (Cornell University), Dave Katz (MERIT), Matt Mathis (PSC), Yakov Rekhter (IBM), and Jessica Yu (MERIT).
このドキュメントはジェフリー・C.ホニッグ(コーネル大学)、デーヴ・キャッツ(MERIT)、マット・マシス(PSC)、ヤコフRekhter(IBM)、およびジェシカ・ユー(MERIT)によって共同で書かれた1990年6月に元々、RFC1164として発表されました。
The following also made key contributions to RFC 1164 -- Guy Almes (ANS, then at Rice University), Kirk Lougheed (cisco Systems), Hans- Werner Braun (SDSC, then at MERIT), and Sue Hares (MERIT).
また、以下が主要な貢献をした、RFC1164--奴のAlmes(そして、ライス大学のANS)、カーク・ロッキード(コクチマスSystems)、ハンスヴェルナーBraun(そして、MERITのSDSC)、およびスーHares(MERIT)。
We like to explicitly thank Bob Braden (ISI) for the review of the previous version of this document.
私たちは、このドキュメントの旧バージョンのレビューについて明らかにボブ・ブレーデン(ISI)に感謝するのが好きです。
This updated version of the document is the product of the IETF BGP Working Group with Phill Gross (MCI) and Yakov Rekhter (IBM) as editors.
ドキュメントのこのアップデートされたバージョンはエディタとしてのフィルGross(MCI)とヤコフRekhter(IBM)があるIETF BGP作業部会の製品です。
Rekhter & Gross [Page 1] RFC 1772 BGP-4 Application March 1995
1995年のRekhterと[1ページ]総計のRFC1772BGP-4アプリケーション行進
John Moy (Proteon) contributed Section 7 "Required set of supported routing policies".
ジョンMoy(Proteon)は「支持されたルーティング方針をセットに要求する」というセクション7を寄付しました。
Scott Brim (Cornell University) contributed the basis for Section 8 "Interaction with other exterior routing protocols".
スコットBrim(コーネル大学)は「他の外のルーティング・プロトコルとの相互作用」というセクション8の基礎を寄付しました。
Most of the text in Section 9 was contributed by Gerry Meyer (Spider).
セクション9のテキストの大部分はゲリー・マイヤー(クモ)によって寄付されました。
Parts of the Introduction were taken almost verbatim from [3].
[3]からIntroductionの部分をほぼ逐語的に取りました。
We would like to acknowledge Dan Long (NEARNET) and Tony Li (cisco Systems) for their review and comments on the current version of the document.
ドキュメントの最新版の彼らのレビューとコメントのために、ダンLong(NEARNET)とトニー・李(コクチマスSystems)を承認したいと思います。
The work of Yakov Rekhter was supported in part by the National Science Foundation under Grant Number NCR-9219216.
ヤコフRekhterの仕事はグラントNumber NCR-9219216の下で国立科学財団によって一部支持されました。
1. Introduction
1. 序論
This memo describes the use of the Border Gateway Protocol (BGP) [1] in the Internet environment. BGP is an inter-Autonomous System routing protocol. The network reachability information exchanged via BGP provides sufficient information to detect routing loops and enforce routing decisions based on performance preference and policy constraints as outlined in RFC 1104 [2]. In particular, BGP exchanges routing information containing full AS paths and enforces routing policies based on configuration information.
このメモはインターネット環境におけるボーダ・ゲイトウェイ・プロトコル(BGP)[1]の使用について説明します。 BGPは相互Autonomous Systemルーティング・プロトコルです。 BGPを通して交換されたネットワーク可到達性情報は、ルーティング輪を検出して、RFC1104[2]に概説されているように性能好みと方針規制に基づくルーティング決定を実施するために十分な情報を提供します。 BGPは特に、完全なAS経路を含むルーティング情報を交換して、設定情報に基づくルーティング方針を実施します。
As the Internet has evolved and grown over in recent years, it has become painfully evident that it is soon to face several serious scaling problems. These include:
近年インターネットが発展して、終わるようになるのに従って、すぐいくつかの重大なスケーリング問題これらのインクルードに直面していることになっているのは痛々しいほど明白になりました:
- Exhaustion of the class-B network address space. One
fundamental cause of this problem is the lack of a network
class of a size which is appropriate for mid-sized
organization; class-C, with a maximum of 254 host addresses, is
too small while class-B, which allows up to 65534 addresses, is
too large to be densely populated.
- クラスBネットワークアドレス空間の疲労困憊。 この問題の1つの根本的要因が中型の組織に、適切なサイズのネットワークのクラスの不足です。 最大254のホスト・アドレスで、クラスB(最大65534のアドレスを許容する)は人口密度が高いように思えないほど大きいのですが、クラスCは小さ過ぎます。
- Growth of routing tables in Internet routers are beyond the
ability of current software (and people) to effectively manage.
- インターネットルータにおけるテーブルが現在のソフトウェア(そして、人々)の能力を超えた事実上、管理するためにはものであるルーティングの成長。
- Eventual exhaustion of the 32-bit IP address space.
- 32ビットのIPアドレス空間の最後の疲労困憊。
It has become clear that the first two of these problems are likely to become critical within the next one to three years. Classless inter-domain routing (CIDR) attempts to deal with these problems by
これらの2つの最初の問題が1〜3年以内に批判的になりそうであるのは明確になりました。 階級のない相互ドメインルーティング(CIDR)は、これらの問題に対処するのを試みます。
Rekhter & Gross [Page 2] RFC 1772 BGP-4 Application March 1995
1995年のRekhterと[2ページ]総計のRFC1772BGP-4アプリケーション行進
proposing a mechanism to slow the growth of the routing table and the need for allocating new IP network numbers. It does not attempt to solve the third problem, which is of a more long-term nature, but instead endeavors to ease enough of the short to mid-term difficulties to allow the Internet to continue to function efficiently while progress is made on a longer-term solution.
経路指定テーブルの成長と新しいIPネットワーク・ナンバーを割り当てる必要性を遅くするためにメカニズムを提案します。 それは、3番目の、より長期的に自然な問題を解決するのを試みませんが、短さでインターネットが、進歩が、より長い期間ソリューションで見られる間、効率的に機能し続けているのを許容できるくらい中期の困難の船首を風上に向けるよう代わりに努力します。
BGP-4 is an extension of BGP-3 that provides support for routing information aggregation and reduction based on the Classless inter- domain routing architecture (CIDR) [3]. This memo describes the usage of BGP-4 in the Internet.
BGP-4はルーティング情報集合のサポートを提供するBGP-3とClassless相互ドメインルーティング構造(CIDR)[3]に基づく減少の拡大です。 このメモはインターネットでBGP-4の使用法を説明します。
All of the discussions in this paper are based on the assumption that the Internet is a collection of arbitrarily connected Autonomous Systems. That is, the Internet will be modeled as a general graph whose nodes are AS's and whose edges are connections between pairs of AS's.
この紙における議論のすべてがインターネットが任意に接続されたAutonomous Systemsの収集であるという仮定に基づいています。すなわち、インターネットはノードがASのものであり、縁がASの組の間の接続である一般的なグラフとしてモデル化されるでしょう。
The classic definition of an Autonomous System is a set of routers under a single technical administration, using an interior gateway protocol and common metrics to route packets within the AS and using an exterior gateway protocol to route packets to other AS's. Since this classic definition was developed, it has become common for a single AS to use several interior gateway protocols and sometimes several sets of metrics within an AS. The use of the term Autonomous System here stresses the fact that, even when multiple IGPs and metrics are used, the administration of an AS appears to other AS's to have a single coherent interior routing plan and presents a consistent picture of which destinations are reachable through it.
Autonomous Systemの古典的な定義はただ一つの技術的な管理の下で、1セットのルータです、ASの中でパケットを発送するのに内部のゲートウェイプロトコルと一般的な測定基準を使用して、ASの他のものにパケットを発送するのに外のゲートウェイプロトコルを使用して。 この古典的な定義が開発されて以来、独身のASがASの中でいくつかの内部のゲートウェイプロトコルと時々数セットの測定基準を使用するのは一般的になっています。 ここでのAutonomous Systemという用語の使用は、ただ一つの論理的な内部のルーティングプランを持つために、複数のIGPsと測定基準が使用されてさえいるとき、ASの管理がASの他のものにおいて現れるという事実を強調して、目的地がそれを通して届いている一貫した絵を提示します。
AS's are assumed to be administered by a single administrative entity, at least for the purposes of representation of routing information to systems outside of the AS.
少なくともルーティング情報の表現の目的のためにASの外でただ一つの管理実体によってASのものによってシステムに管理されると思われます。
2. BGP Topological Model
2. BGP位相モデル
When we say that a connection exists between two AS's, we mean two things:
ASのもの、接続が2の間に存在すると言うとき、私たちは2つのものを言っています:
Physical connection: There is a shared Data Link subnetwork
between the two AS's, and on this shared subnetwork each AS has at
least one border gateway belonging to that AS. Thus the border
gateway of each AS can forward packets to the border gateway of
the other AS without resorting to Inter-AS or Intra-AS routing.
物理接続: ASの2ところの間には、共有されたData Linkサブネットワークがあります、そして、この共有されたサブネットワークの上では、各ASは少なくとも1境界門にそのASに属させます。 したがって、Inter-ASかIntra-ASルーティングに頼らないで、それぞれのASの境界ゲートウェイは他のASの境界ゲートウェイにパケットを送ることができます。
BGP connection: There is a BGP session between BGP speakers in
each of the AS's, and this session communicates those routes that
can be used for specific destinations via the advertising AS.
BGP接続: それぞれのASのところのBGPスピーカーの間には、BGPセッションがあります、そして、このセッションは特定の目的地に広告ASを通して使用できるそれらのルートを伝えます。
Rekhter & Gross [Page 3] RFC 1772 BGP-4 Application March 1995
1995年のRekhterと[3ページ]総計のRFC1772BGP-4アプリケーション行進
Throughout this document we place an additional restriction on the
BGP speakers that form the BGP connection: they must themselves
share the same Data Link subnetwork that their border gateways
share. Thus, a BGP session between adjacent AS's requires no
support from either Inter-AS or Intra-AS routing. Cases that do
not conform to this restriction fall outside the scope of this
document.
このドキュメント中では、私たちはBGP接続を形成するBGPスピーカーに関して追加制限を課します: そうしなければならない、自分たち、それらの境界ゲートウェイが共有するのと同じData Linkサブネットワークを共有してください。 Thus, a BGP session between adjacent AS's requires no support from either Inter-AS or Intra-AS routing. この制限に一致していないケースはこのドキュメントの範囲をそらせます。
Thus, at each connection, each AS has one or more BGP speakers and one or more border gateways, and these BGP speakers and border gateways are all located on a shared Data Link subnetwork. Note that BGP speakers do not need to be a border gateway, and vice versa. Paths announced by a BGP speaker of one AS on a given connection are taken to be feasible for each of the border gateways of the other AS on the same shared subnetwork, i.e. indirect neighbors are allowed.
したがって、各接続のときに、各ASには1人以上のBGPスピーカーと1境界門以上があります、そして、これらのBGPスピーカーと境界ゲートウェイは共有されたData Linkサブネットワークの上にすべて位置しています。 BGPスピーカーが、境界ゲートウェイである必要でないことに注意してください、そして、逆もまた同様です。 同じ共有されたサブネットワークでそれぞれの他のASの境界ゲートウェイに可能になるように1ASのBGPスピーカーによって与えられた接続に発表された経路を取ります、すなわち、間接的な隣人を許容します。
Much of the traffic carried within an AS either originates or terminates at that AS (i.e., either the source IP address or the destination IP address of the IP packet identifies a host internal to that AS). Traffic that fits this description is called "local traffic". Traffic that does not fit this description is called "transit traffic". A major goal of BGP usage is to control the flow of transit traffic.
ASの中で運ばれた交通の大部分は、おまけに、ASを溯源するか、または終えます(すなわち、IPパケットのソースIPアドレスか送付先IPアドレスのどちらかがそのASへの内部のホストを特定します)。 この記述に合う交通は「ローカルの交通」と呼ばれます。 この記述に合わない交通は「トランジット交通」と呼ばれます。 BGP用法の主要な目標はトランジット交通の流れを制御することです。
Based on how a particular AS deals with transit traffic, the AS may now be placed into one of the following categories:
どうトランジット交通に対処するかに基づいて、ASは現在、以下のカテゴリの1つに置かれるかもしれません:
stub AS: an AS that has only a single connection to one other AS.
Naturally, a stub AS only carries local traffic.
ASを引き抜いてください: 単独結合しか他の1ASまでないAS。 当然、スタッブASはローカルの交通を運ぶだけです。
multihomed AS: an AS that has connections to more than one other
AS, but refuses to carry transit traffic.
multihomed AS: 接続が他の1ASまでありますが、トランジット交通を運ぶのを拒否するAS。
transit AS: an AS that has connections to more than one other AS,
and is designed (under certain policy restrictions) to carry both
transit and local traffic.
トランジットAS: 接続が他の1ASまであって、トランジットとローカルの交通の両方を運ぶように設計されている(ある方針制限で)AS。
Since a full AS path provides an efficient and straightforward way of suppressing routing loops and eliminates the "count-to-infinity" problem associated with some distance vector algorithms, BGP imposes no topological restrictions on the interconnection of AS's.
完全なAS経路がルーティング輪を抑圧する効率的で簡単な方法を提供して、いくつかの距離ベクトルアルゴリズムに関連している「無限カウント」問題を解決するので、BGPはASのインタコネクトにどんな位相的な制限も課しません。
Rekhter & Gross [Page 4] RFC 1772 BGP-4 Application March 1995
1995年のRekhterと[4ページ]総計のRFC1772BGP-4アプリケーション行進
3. BGP in the Internet
3. インターネットのBGP
3.1 Topology Considerations
3.1 トポロジー問題
The overall Internet topology may be viewed as an arbitrary interconnection of transit, multihomed, and stub AS's. In order to minimize the impact on the current Internet infrastructure, stub and multihomed AS's need not use BGP. These AS's may run other protocols (e.g., EGP) to exchange reachability information with transit AS's. Transit AS's using BGP will tag this information as having been learned by some method other than BGP. The fact that BGP need not run on stub or multihomed AS's has no negative impact on the overall quality of inter-AS routing for traffic that either destined to or originated from the stub or multihomed AS's in question.
総合的なインターネットトポロジーは、「マルチ-家へ帰」ったトランジットの任意のインタコネクトとして見なされて、ASのものを引き抜くかもしれません。 現在のインターネット基盤への影響を最小にするために、スタッブとmultihomed ASの必要性はBGPを使用しません。 ASのこれらのものは、トランジットASのものと可到達性情報を交換するために、他のプロトコル(例えば、EGP)を走らせるかもしれません。 トランジットASがBGPを使用すると、BGP以外の何らかの方法によって学習されたとしてこの情報はタグ付けをされるでしょう。 BGPがスタッブかmultihomed ASのものの上で作業する必要はないという事実はスタッブから運命づけたか、または発した交通のための相互ASルーティングかmultihomed ASの問題の総合的な品質に負の衝撃を全く持っていません。
However, it is recommended that BGP be used for stub and multihomed AS's as well. In these situations, BGP will provide an advantage in bandwidth and performance over some of the currently used protocols (such as EGP). In addition, this would reduce the need for the use of default routes and in better choices of Inter-AS routes for multihomed AS's.
しかしながら、また、BGPがスタッブとmultihomed ASのものに使用されるのは、お勧めです。 これらの状況で、BGPは現在中古のプロトコル(EGPなどの)のいくつか上で帯域幅と性能に利点を提供するでしょう。 さらに、これはデフォルトルートの使用とInter-ASルートの、より良い選択における、multihomed ASの必要性を減少させるでしょう。
3.2 Global Nature of BGP
3.2 BGPのグローバルなネイチャー
At a global level, BGP is used to distribute routing information among multiple Autonomous Systems. The information flows can be represented as follows:
グローバルなレベルでは、複数のAutonomous Systemsにルーティング情報を分配するのにBGPを使用します。以下の通り情報流れを表すことができます:
+-------+ +-------+
BGP | BGP | BGP | BGP | BGP
---------+ +---------+ +---------
| IGP | | IGP |
+-------+ +-------+
+-------+ +-------+ BGP| BGP| BGP| BGP| BGP---------+ +---------+ +--------- | IGP| | IGP| +-------+ +-------+
<-AS A--> <--AS B->
<、-、B->としてのA(><)
This diagram points out that, while BGP alone carries information between AS's, both BGP and an IGP may carry information across an AS. Ensuring consistency of routing information between BGP and an IGP within an AS is a significant issue and is discussed at length later in Appendix A.
このダイヤグラムは、BGPだけがASのものの間まで情報を運ぶ間BGPとIGPの両方がASの向こう側に情報を運ぶかもしれないと指摘します。 ASの中のBGPとIGPの間のルーティング情報について一貫性があることを保証するのと、重要な問題であり、後で十分Appendix Aで議論します。
3.3 BGP Neighbor Relationships
3.3 BGP隣人関係
The Internet is viewed as a set of arbitrarily connected AS's. Routers that communicate directly with each other via BGP are known as BGP speakers. BGP speakers can be located within the same AS or in different AS's. BGP speakers in each AS communicate with each other
インターネットは任意に接続されたASのものの1セットとして見なされます。 互いと共にBGPを通して直接伝達するルータはBGPスピーカーとして知られています。 BGP speakers can be located within the same AS or in different AS's. 各ASのBGPスピーカーは互いにコミュニケートします。
Rekhter & Gross [Page 5] RFC 1772 BGP-4 Application March 1995
1995年のRekhterと[5ページ]総計のRFC1772BGP-4アプリケーション行進
to exchange network reachability information based on a set of policies established within each AS. For a given BGP speaker, some other BGP speaker with which the given speaker communicates is referred to as an external peer if the other speaker is in a different AS, while if the other speaker is in the same AS it is referred to as an internal peer.
ネットワーク可到達性情報を交換するのは各ASを中で確立した方針のセットに基礎づけました。 与えられたBGPスピーカーに関しては、もう片方のスピーカーが異なったASにいるなら、与えられたスピーカーと交信するある他のBGPスピーカーは外部の同輩と呼ばれます、もう片方のスピーカーが同じASにいるなら、それが内部の同輩と呼ばれますが。
There can be as many BGP speakers as deemed necessary within an AS. Usually, if an AS has multiple connections to other AS's, multiple BGP speakers are needed. All BGP speakers representing the same AS must give a consistent image of the AS to the outside. This requires that the BGP speakers have consistent routing information among them. These gateways can communicate with each other via BGP or by other means. The policy constraints applied to all BGP speakers within an AS must be consistent. Techniques such as using a tagged IGP (see A.2.2) may be employed to detect possible inconsistencies.
ASの中で必要であると考えられるのと同じくらい多くのBGPスピーカーがいることができます。 通常、ASの他のものにASが複数の接続がいるなら、複数のBGPスピーカーが必要です。 同じASを表すすべてのBGPスピーカーがASの一貫したイメージを外部に与えなければなりません。 これは、BGPスピーカーが彼らの中に一貫したルーティング情報を持っているのを必要とします。 これらのゲートウェイはBGPを通して他の手段で互いと交信できます。 ASの中のすべてのBGPスピーカーに適用された方針規制は一貫しているに違いありません。 タグ付けをされたIGP(A.2.2を見る)を使用などなどのテクニックは、可能な矛盾を検出するのに使われるかもしれません。
In the case of external peers, the peers must belong to different AS's, but share a common Data Link subnetwork. This common subnetwork should be used to carry the BGP messages between them. The use of BGP across an intervening AS invalidates the AS path information. An Autonomous System number must be used with BGP to specify which Autonomous System the BGP speaker belongs to.
外部の同輩の場合では、同輩は異なったASのものに属さなければなりませんが、一般的なData Linkサブネットワークを共有してください。 この一般的なサブネットワークは、BGPメッセージをそれらに伝えるのに使用されるべきです。 介入しているASの向こう側のBGPの使用はAS経路情報を無効にします。 BGPスピーカーがどのAutonomous Systemに属すかを指定するのにBGPと共にAutonomous System番号を使用しなければなりません。
4. Requirements for Route Aggregation
4. ルート集合のための要件
A conformant BGP-4 implementation is required to have the ability to specify when an aggregated route may be generated out of partial routing information. For example, a BGP speaker at the border of an autonomous system (or group of autonomous systems) must be able to generate an aggregated route for a whole set of destination IP addresses (in BGP-4 terminology such a set is called the Network Layer Reachability Information or NLRI) over which it has administrative control (including those addresses it has delegated), even when not all of them are reachable at the same time.
conformant BGP-4実現が、集められたルートがいつ部分的なルーティング情報から発生するかもしれないかを指定する能力を持つのに必要です。 例えば、自律システム(または、自律システムのグループ)の境界のBGPスピーカーはそれが運営管理コントロールを持っている1つの全体集合の送付先IPアドレス(BGP-4用語で、そのようなセットはNetwork Layer Reachability情報かNLRIと呼ばれる)のために集められたルートを発生させることができなければなりません(それが代表として派遣したそれらのアドレスを含んでいて)、それらが皆、同時に届くというわけではないときさえ。
A conformant implementation may provide the capability to specify when an aggregated NLRI may be generated.
conformant実現は集められたNLRIがいつ発生するかもしれないかを指定する能力を提供するかもしれません。
A conformant implementation is required to have the ability to specify how NLRI may be de-aggregated.
conformant実現が、NLRIがどう反-集められるかもしれないかを指定する能力を持つのに必要です。
A conformant implementation is required to support the following options when dealing with overlapping routes:
conformant実現が重なっているルートに対処するとき、以下のオプションをサポートするのに必要です:
- Install both the less and the more specific routes
- 少しもよりそして、より特定のルートをインストールしないでください。
- Install the more specific route only
- より特定のルートだけをインストールしてください。
Rekhter & Gross [Page 6] RFC 1772 BGP-4 Application March 1995
1995年のRekhterと[6ページ]総計のRFC1772BGP-4アプリケーション行進
- Install the less specific route only
- それほど特定でないルートだけをインストールしてください。
- Install neither route
- どちらのルートもインストールしないでください。
Certain routing policies may depend on the NLRI (e.g. "research" versus "commercial"). Therefore, a BGP speaker that performs route aggregation should be cognizant, if possible, of potential implications on routing policies when aggregating NLRI.
あるルーティング方針はNLRI(例えば、「コマーシャル」に対する「研究」)によるかもしれません。 したがって、NLRIに集めるとき、できれば、ルート集合を実行するBGPスピーカーはルーティング方針で潜在的含意を認識しているべきです。
5. Policy Making with BGP
5. BGPとの政策立案
BGP provides the capability for enforcing policies based on various routing preferences and constraints. Policies are not directly encoded in the protocol. Rather, policies are provided to BGP in the form of configuration information.
BGPは様々なルーティング好みと規制に基づく方針を実施するのに能力を提供します。 方針はプロトコルで直接コード化されません。 むしろ、設定情報の形で方針をBGPに提供します。
BGP enforces policies by affecting the selection of paths from multiple alternatives and by controlling the redistribution of routing information. Policies are determined by the AS administration.
BGPは、複数の選択肢から経路の品揃えに影響して、ルーティング情報の再分配を制御することによって、方針を実施します。 方針はAS管理によって決定されます。
Routing policies are related to political, security, or economic considerations. For example, if an AS is unwilling to carry traffic to another AS, it can enforce a policy prohibiting this. The following are examples of routing policies that can be enforced with the use of BGP:
ルート設定方針は政治上の、または、安全か、経済の問題に関連します。 例えば、ASが別のASまで交通を運びたがっていないなら、それはこれを禁止する方針を実施できます。 ↓これはBGPの使用で励行されることができるルーティング方針に関する例です:
1. A multihomed AS can refuse to act as a transit AS for other
AS's. (It does so by only advertising routes to destinations
internal to the AS.)
1. multihomed ASは、ASの他のもののためのトランジットASとして機能するのを拒否できます。 (それは広告ルートだけでそうASへの内部の目的地にします。)
2. A multihomed AS can become a transit AS for a restricted set of
adjacent AS's, i.e., some, but not all, AS's can use the
multihomed AS as a transit AS. (It does so by advertising its
routing information to this set of AS's.)
2. multihomed ASはすなわち、隣接しているASのもの、何らかの制限されたセットのトランジットASになりますが、すべてなることができないで、ASのものはトランジットASとしてmultihomed ASを使用できます。 (それは広告でそうASのこのセットにルーティング情報をします。)
3. An AS can favor or disfavor the use of certain AS's for
carrying transit traffic from itself.
3. ASはあるASのもののそれ自体からトランジット交通を運ぶ使用を支持するか、または疎んじることができます。
A number of performance-related criteria can be controlled with the use of BGP:
BGPの使用で多くの性能関連の評価基準を制御できます:
1. An AS can minimize the number of transit AS's. (Shorter AS
paths can be preferred over longer ones.)
1. ASはトランジットASの数を最小にすることができます。 (より長いものより短いAS経路を好むことができます。)
2. The quality of transit AS's. If an AS determines that two or
more AS paths can be used to reach a given destination, that AS
can use a variety of means to decide which of the candidate AS
2. トランジットASの品質。 ASが、ASが与えられた目的地に達するのに2つ以上のAS経路を使用できて、候補ASにどれを決めるかさまざまな手段を使用できることを決定するなら
Rekhter & Gross [Page 7] RFC 1772 BGP-4 Application March 1995
1995年のRekhterと[7ページ]総計のRFC1772BGP-4アプリケーション行進
paths it will use. The quality of an AS can be measured by such
things as diameter, link speed, capacity, tendency to become
congested, and quality of operation. Information about these
qualities might be determined by means other than BGP.
それが使用する経路。 操作の直径、リンク速度、容量、混雑するようになる傾向、および品質のようなものはASの品質を測定できます。 これらの品質に関する情報はBGP以外の手段で決定するかもしれません。
3. Preference of internal routes over external routes.
3. 外部経路の上の内部のルートの好み。
For consistency within an AS, equal cost paths, resulting from combinations of policies and/or normal route selection procedures, must be resolved in a consistent fashion.
ASの中の一貫性において、一貫したファッションで等しい費用経路(方針の組み合わせから生じる、そして/または、ノーマルルート選択手順)を決議しなければなりません。
Fundamental to BGP is the rule that an AS advertises to its neighboring AS's only those routes that it uses. This rule reflects the "hop-by-hop" routing paradigm generally used by the current Internet.
BGPへの基本的はASがそれが使用するそれらのルートだけの隣接しているASのものに広告を出すという規則です。 この規則は一般に、現在のインターネットによって使用される「ホップごとの」ルーティングパラダイムを反映します。
6. Path Selection with BGP
6. BGPとの経路選択
One of the major tasks of a BGP speaker is to evaluate different paths from itself to a set of destination covered by an address prefix, select the best one, apply appropriate policy constraints, and then advertise it to all of its BGP neighbors. The key issue is how different paths are evaluated and compared. In traditional distance vector protocols (e.g., RIP) there is only one metric (e.g., hop count) associated with a path. As such, comparison of different paths is reduced to simply comparing two numbers. A complication in Inter-AS routing arises from the lack of a universally agreed-upon metric among AS's that can be used to evaluate external paths. Rather, each AS may have its own set of criteria for path evaluation.
BGPスピーカーの主タスクの1つは、BGP隣人のすべてにそれ自体からアドレス接頭語で覆われた1セットの目的地まで異なった経路を評価して、最も良い方を選択して、適切な方針規制を適用して、次に、それの広告を出すことです。 主要な問題は異なった経路がどう評価されて、比較されるかということです。 伝統的な距離ベクトルプロトコル(例えば、RIP)には、1つしかメートル法であることで(例えば、カウントを飛び越します)ありません。経路に関連しています。 そういうものとして、異なった経路の比較は単に2つの番号を比較するのに抑えられます。 Inter-ASルーティングにおける複雑さは外部の経路を評価するのに使用できるASのところで一般にメートル法で同意されたaの不足から起こります。 むしろ、各ASには、それ自身の経路評価の評価基準のセットがあるかもしれません。
A BGP speaker builds a routing database consisting of the set of all feasible paths and the list of destinations (expressed as address prefixes) reachable through each path. For purposes of precise discussion, it's useful to consider the set of feasible paths for a set of destinations associated with a given address prefix. In most cases, we would expect to find only one feasible path. However, when this is not the case, all feasible paths should be maintained, and their maintenance speeds adaptation to the loss of the primary path. Only the primary path at any given time will ever be advertised.
BGPスピーカーはすべての実行可能経路のセットと各経路を通して届いている目的地(アドレス接頭語として、言い表される)のリストから成るルーティングデータベースを築き上げます。 正確な議論の目的に、1セットの目的地への実行可能経路のセットが与えられたアドレス接頭語に関連していると考えるのは役に立ちます。 多くの場合、私たちは、1つの実行可能経路だけを見つけると予想するでしょう。 しかしながら、これがそうでないときに、すべての実行可能経路が維持されるべきです、そして、彼らの維持は第一の経路の損失への適合を促進します。 今までに、その時々で第一の経路だけの広告を出すでしょう。
The path selection process can be formalized by defining a complete order over the set of all feasible paths to a set of destinations associated with a given address prefix. One way to define this complete order is to define a function that maps each full AS path to a non-negative integer that denotes the path's degree of preference. Path selection is then reduced to applying this function to all feasible paths and choosing the one with the highest degree of preference.
与えられたアドレス接頭語に関連している目的地のセットとすべての実行可能経路のセットの完全な注文を定義することによって、経路選択の過程を正式にすることができます。 この完全なオーダーを定義する1つの方法は経路の好みの度合いを指示する非負の整数にそれぞれの完全なAS経路を写像する機能を定義することです。 そして、経路選択はこの機能をすべての実行可能経路に適用して、最も高度の好みでものを選ぶのに抑えられます。
Rekhter & Gross [Page 8] RFC 1772 BGP-4 Application March 1995
1995年のRekhterと[8ページ]総計のRFC1772BGP-4アプリケーション行進
In actual BGP implementations, the criteria for assigning degree of preferences to a path are specified as configuration information.
実際のBGP実現では、好みの度合いを経路に割り当てる評価基準は設定情報として指定されます。
The process of assigning a degree of preference to a path can be based on several sources of information:
1段階の好みを経路に割り当てる過程は数個の情報筋に基づくことができます:
1. Information explicitly present in the full AS path.
1. 完全なAS経路の明らかに現在の情報。
2. A combination of information that can be derived from the full
AS path and information outside the scope of BGP (e.g., policy
routing constraints provided as configuration information).
2. BGP(例えば設定情報として提供された方針ルーティング規制)の範囲の外で完全なAS経路と情報から得ることができる情報の組み合わせ。
Possible criteria for assigning a degree of preference to a path are:
1段階の好みを経路に割り当てる可能な評価基準は以下の通りです。
- AS count. Paths with a smaller AS count are generally better.
- ASは数えます。 一般に、より小さいASカウントがある経路は、より良いです。
- Policy considerations. BGP supports policy-based routing based
on the controlled distribution of routing information. A BGP
speaker may be aware of some policy constraints (both within
and outside of its own AS) and do appropriate path selection.
Paths that do not comply with policy requirements are not
considered further.
- 方針問題。 BGPはルーティング情報の制御分配に基づく方針ベースのルーティングを支持します。 BGPスピーカーは、いくつかの方針規制を意識していて(それ自身のASの中、外)、適切な経路選択をするかもしれません。 方針要件に従わない経路がさらに考えられません。
- Presence or absence of a certain AS or AS's in the path. By
means of information outside the scope of BGP, an AS may know
some performance characteristics (e.g., bandwidth, MTU, intra-
AS diameter) of certain AS's and may try to avoid or prefer
them.
- 経路のあるASかASの存在か不在。 BGPの範囲の外の情報によって、ASは彼らをあるASのもののいくつかの性能の特性(例えば、帯域幅、MTU、イントラAS直径)を知って、避けようとするか、または好もうとするかもしれません。
- Path origin. A path learned entirely from BGP (i.e., whose
endpoint is internal to the last AS on the path) is generally
better than one for which part of the path was learned via EGP
or some other means.
- 経路の起源。 一般に、完全なBGP(すなわち、終点が経路の最後のASに内部である)から学習された経路は経路の一部がEGPを通して学習されたものかある他の手段より良いです。
- AS path subsets. An AS path that is a subset of a longer AS
path to the same destination should be preferred over the
longer path. Any problem in the shorter path (such as an
outage) will also be a problem in the longer path.
- AS経路部分集合。 同じ目的地への、より長いAS経路の部分集合であるAS経路は、より長い経路より好まれるべきです。 また、より短い経路(供給停止などの)のどんな問題もより長い経路で問題になるでしょう。
- Link dynamics. Stable paths should be preferred over unstable
ones. Note that this criterion must be used in a very careful
way to avoid causing unnecessary route fluctuation. Generally,
any criteria that depend on dynamic information might cause
routing instability and should be treated very carefully.
- 力学をリンクしてください。 安定路線は不安定なものより好まれるべきです。 不要なルート変動を引き起こすのを避ける非常に慎重な方法でこの評価基準を使用しなければならないことに注意してください。 一般に、動的情報に依存するどんな評価基準も、ルーティングの不安定性を引き起こすかもしれなくて、非常に慎重に扱われるべきです。
Rekhter & Gross [Page 9] RFC 1772 BGP-4 Application March 1995
1995年のRekhterと[9ページ]総計のRFC1772BGP-4アプリケーション行進
7. Required set of supported routing policies
7. 必要なセットの支持されたルーティング方針
Policies are provided to BGP in the form of configuration information. This information is not directly encoded in the protocol. Therefore, BGP can provide support for very complex routing policies. However, it is not required that all BGP implementations support such policies.
設定情報の形で方針をBGPに提供します。 この情報はプロトコルで直接コード化されません。 したがって、BGPは非常に複雑なルーティング方針のサポートを提供できます。 しかしながら、すべてのBGP実現がそのような方針を支持するのが必要ではありません。
We are not attempting to standardize the routing policies that must be supported in every BGP implementation; we strongly encourage all implementors to support the following set of routing policies:
私たちは、あらゆるBGP実現で支持しなければならないルーティング方針を標準化するのを試みていません。 私たちは、すべての作成者が以下のセットのルーティング方針を支持するよう強く奨励します:
1. BGP implementations should allow an AS to control announcements
of BGP-learned routes to adjacent AS's. Implementations should
also support such control with at least the granularity of a
single address prefix. Implementations should also support
such control with the granularity of an autonomous system,
where the autonomous system may be either the autonomous system
that originated the route, or the autonomous system that
advertised the route to the local system (adjacent autonomous
system). Care must be taken when a BGP speaker selects a new
route that can't be announced to a particular external peer,
while the previously selected route was announced to that peer.
Specifically, the local system must explicitly indicate to the
peer that the previous route is now infeasible.
1. ASはBGP実現からBGPが学術的なルートの発表を隣接しているASのものに制御するはずであることができます。 また、実現は少なくともただ一つのアドレス接頭語の粒状でそのようなコントロールを支持するべきです。 また、実現は自律システム、自律システムがどこのルートを溯源した自律システムであるかもしれないか、そして、または自律システムの粒状があるローカルシステム(隣接している自律システム)にルートの広告を出したそのようなコントロールを支持するべきです。 BGPスピーカーが特定の外部の同輩に発表できない新しいルートを選択するとき、注意しなければなりません、以前に選択されたルートはその同輩に発表されましたが。 明確に、ローカルシステムは、前のルートが現在実行不可能であることを同輩に明らかに示さなければなりません。
2. BGP implementations should allow an AS to prefer a particular
path to a destination (when more than one path is available).
At the minimum an implementation shall support this
functionality by allowing to administratively assign a degree
of preference to a route based solely on the IP address of the
neighbor the route is received from. The allowed range of the
assigned degree of preference shall be between 0 and 2^(31) -
1.
2. ASは目的地よりBGP実現で特定の経路を好むはずであることができます(1つ以上の経路が利用可能であるときに)。 最小限では、行政上唯一ルートが受け取られる隣人のIPアドレスに基づくルートに1段階の好みを割り当てるのを許容することによって、実現はこの機能性を支持するものとします。 許容範囲の割り当てられた度の好みは0〜2^にな(31)るでしょう--1。
3. BGP implementations should allow an AS to ignore routes with
certain AS's in the AS_PATH path attribute. Such function can
be implemented by using the technique outlined in [2], and by
assigning "infinity" as "weights" for such AS's. The route
selection process must ignore routes that have "weight" equal
to "infinity".
3. ASはBGP実現でAS_PATH経路属性で、あるASのものがあるルートを無視するはずであることができます。 [2]に概説されたテクニックを使用して、ASのそのようなもののための「重り」として「無限」を割り当てることによって、そのような機能を実行できます。 ルート選択の過程は「無限」と等しい「重さ」を持っているルートを無視しなければなりません。
8. Interaction with other exterior routing protocols
8. 他の外のルーティング・プロトコルとの相互作用
The guidelines suggested in this section are consistent with the guidelines presented in [3].
このセクションで示されたガイドラインは[3]に提示されるガイドラインと一致しています。
Rekhter & Gross [Page 10] RFC 1772 BGP-4 Application March 1995
1995年のRekhterと[10ページ]総計のRFC1772BGP-4アプリケーション行進
An AS should advertise a minimal aggregate for its internal destinations with respect to the amount of address space that it is actually using. This can be used by administrators of non-BGP 4 AS's to determine how many routes to explode from a single aggregate.
ASはそれが実際に使用しているアドレス空間の量に関して内部の目的地に最小量の集合の広告を出すはずです。 非BGP4ASの管理者は、ただ一つの集合からいくつのルートを爆発させるかを決定するのにこれを使用できます。
A route that carries the ATOMIC_AGGREGATE path attribute shall not be exported into either BGP-3 or EGP2, unless such an exportation can be accomplished without exploding the NLRI of the route.
ATOMIC_AGGREGATE経路属性を運ぶルートをBGP-3かEGP2のどちらかに輸出しないものとします、ルートのNLRIを爆発させないでそのような輸出を実行できないなら。
8.1 Exchanging information with EGP2
8.1 EGP2と共に情報交換すること。
This document suggests the following guidelines for exchanging routing information between BGP-4 and EGP2.
このドキュメントはBGP-4とEGP2の間でルーティング情報を交換するための以下のガイドラインを示します。
To provide for graceful migration, a BGP speaker may participate in EGP2, as well as in BGP-4. Thus, a BGP speaker may receive IP reachability information by means of EGP2 as well as by means of BGP-4. The information received by EGP2 can be injected into BGP-4 with the ORIGIN path attribute set to 1. Likewise, the information received via BGP-4 can be injected into EGP2 as well. In the latter case, however, one needs to be aware of the potential information explosion when a given IP prefix received from BGP-4 denotes a set of consecutive A/B/C class networks. Injection of BGP-4 received NLRI that denotes IP subnets requires the BGP speaker to inject the corresponding network into EGP2. The local system shall provide mechanisms to control the exchange of reachability information between EGP2 and BGP-4. Specifically, a conformant implementation is required to support all of the following options when injecting BGP-4 received reachability information into EGP2:
優雅な移動に備えるために、BGPスピーカーはEGP2、およびBGP-4に参加するかもしれません。 したがって、BGPスピーカーはEGP2によるBGP-4によってIP可到達性情報を受け取るかもしれません。 ORIGIN経路属性セットでEGP2によって受け取られた情報はBGP-4に1まで注ぐことができます。 同様に、BGP-4を通して受け取られた情報はまた、EGP2に注ぐことができます。 しかしながら、後者の場合では、人は、BGP-4から受け取られた与えられたIP接頭語が1セットの連続したA/B/Cクラスネットワークを指示するとき、潜在的情力化を意識している必要があります。 IPサブネットを指示するBGP-4の容認されたNLRIの注射は、BGPスピーカーが対応するネットワークをEGP2に注ぐのを必要とします。 ローカルシステムは、EGP2とBGP-4の間の可到達性情報の交換を制御するためにメカニズムを提供するものとします。 明確に、conformant実現がBGP-4の受信された可到達性情報をEGP2に注ぐとき、以下のオプションのすべてを支持するのに必要です:
- inject default only (0.0.0.0); no export of any other NLRI
- デフォルトだけを注入してください、(0.0、.0、.0)。 いかなる他のNLRIの輸出がありません。
- allow controlled deaggregation, but only of specific routes;
allow export of non-aggregated NLRI
- 制御「反-集合」を許容しますが特定のルートだけについて。 非集められたNLRIの輸出を許容してください。
- allow export of only non-aggregated NLRI
- 非集められたNLRIだけの輸出を許容してください。
The exchange of routing information via EGP2 between a BGP speaker participating in BGP-4 and a pure EGP2 speaker may occur only at the domain (autonomous system) boundaries.
BGP-4に参加するBGPスピーカーと純粋なEGP2スピーカーの間のEGP2を通したルーティング情報の交換はドメイン(自律システム)境界だけに起こるかもしれません。
8.2 Exchanging information with BGP-3
8.2 BGP-3と共に情報交換すること。
This document suggests the following guidelines for exchanging routing information between BGP-4 and BGP-3.
このドキュメントはBGP-4とBGP-3の間でルーティング情報を交換するための以下のガイドラインを示します。
To provide for graceful migration, a BGP speaker may participate in BGP-3, as well as in BGP-4. Thus, a BGP speaker may receive IP
優雅な移動に備えるために、BGPスピーカーはBGP-3、およびBGP-4に参加するかもしれません。 したがって、BGPスピーカーはIPを受けるかもしれません。
Rekhter & Gross [Page 11] RFC 1772 BGP-4 Application March 1995
1995年のRekhterと[11ページ]総計のRFC1772BGP-4アプリケーション行進
reachability information by means of BGP-3, as well as by means of BGP-4.
BGP-3によるBGP-4による可到達性情報。
A BGP speaker may inject the information received by BGP-4 into BGP-3 as follows.
BGPスピーカーはBGP-4によって受け取られた情報を以下のBGP-3に注ぐかもしれません。
If an AS_PATH attribute of a BGP-4 route carries AS_SET path segments, then the AS_PATH attribute of the BGP-3 route shall be constructed by treating the AS_SET segments as AS_SEQUENCE segments, with the resulting AS_PATH being a single AS_SEQUENCE. While this procedure loses set/sequence information, it doesn't affect protection for routing loops suppression, but may affect policies, if the policies are based on the content or ordering of the AS_PATH attribute.
BGP-4ルートのAS_PATH属性がAS_SET経路セグメントを運ぶなら、BGP-3ルートのAS_PATH属性はAS_SEQUENCEセグメントとしてAS_SETセグメントを扱うことによって、構成されるものとします、独身のAS_SEQUENCEである結果として起こるAS_PATHで。 この手順がセット/系列情報を失っている間、ルーティング輪の抑圧のための保護に影響しませんが、方針に影響するかもしれません、方針が内容に基づいているか、またはAS_PATH属性を注文することであるなら。
While injecting BGP-4 derived NLRI into BGP-3, one needs to be aware of the potential information explosion when a given IP prefix denotes a set of consecutive A/B/C class networks. Injection of BGP-4 derived NLRI that denotes IP subnets requires the BGP speaker to inject the corresponding network into BGP-3. The local system shall provide mechanisms to control the exchange of routing information between BGP-3 and BGP-4. Specifically, a conformant implementation is required to support all of the following options when injecting BGP-4 received routing information into BGP-3:
注入BGP-4はNLRIをBGP-3に引き出しましたが、人は、与えられたIP接頭語が1セットの連続したA/B/Cクラスネットワークを指示するとき、潜在的情力化を意識している必要があります。 IPサブネットを指示するBGP-4の引き出しているNLRIの注射は、BGPスピーカーが対応するネットワークをBGP-3に注ぐのを必要とします。 ローカルシステムは、BGP-3とBGP-4の間のルーティング情報の交換を制御するためにメカニズムを提供するものとします。 明確に、conformant実現がBGP-4の受信されたルーティング情報をBGP-3に注ぐとき、以下のオプションのすべてを支持するのに必要です:
- inject default only (0.0.0.0), no export of any other NLRI
- デフォルトだけを注入してください、(0.0、.0、.0、)いかなる他のNLRIの輸出がありません。
- allow controlled deaggregation, but only of specific routes;
allow export of non-aggregated NLRI
- 制御「反-集合」を許容しますが特定のルートだけについて。 非集められたNLRIの輸出を許容してください。
- allow export of only non-aggregated NLRI
- 非集められたNLRIだけの輸出を許容してください。
The exchange of routing information via BGP-3 between a BGP speaker participating in BGP-4 and a pure BGP-3 speaker may occur only at the autonomous system boundaries. Within a single autonomous system BGP conversations between all the BGP speakers of that autonomous system have to be either BGP-3 or BGP-4, but not a mixture.
BGP-4に参加するBGPスピーカーと純粋なBGP-3スピーカーの間のBGP-3を通したルーティング情報の交換は自律システム境界だけに起こるかもしれません。 単一の自律システムの中では、その自律システムのすべてのBGPスピーカーでのBGPの会話は、混合物ではなく、BGP-3かBGP-4のどちらかでなければなりません。
9. Operations over Switched Virtual Circuits
9. 交換仮想回路の上の操作
When using BGP over Switched Virtual Circuit (SVC) subnetworks it may be desirable to minimize traffic generated by BGP. Specifically, it may be desirable to eliminate traffic associated with periodic KEEPALIVE messages. BGP includes a mechanism for operation over switched virtual circuit (SVC) services which avoids keeping SVCs permanently open and allows it to eliminates periodic sending of KEEPALIVE messages.
Switched Virtual Circuit(SVC)サブネットワークの上でBGPを使用するとき、BGPによって発生した交通を最小にするのは望ましいかもしれません。 明確に、周期的なKEEPALIVEメッセージに関連している交通を排除するのは望ましいかもしれません。 (SVC)が永久に開くようにSVCsを保つのを避けるものを修理して、それを許容する交換仮想回路の上の操作がKEEPALIVEメッセージの周期的な発信を排除するので、BGPはメカニズムを含んでいます。
Rekhter & Gross [Page 12] RFC 1772 BGP-4 Application March 1995
1995年のRekhterと[12ページ]総計のRFC1772BGP-4アプリケーション行進
This section describes how to operate without periodic KEEPALIVE messages to minimise SVC usage when using an intelligent SVC circuit manager. The proposed scheme may also be used on "permanent" circuits, which support a feature like link quality monitoring or echo request to determine the status of link connectivity.
このセクションは知的なSVCサーキットマネージャを使用するときSVC用法を最小とならせる周期的なKEEPALIVEメッセージなしで作動する方法を説明します。 また、提案された計画は「永久的な」サーキット、どれがモニターしながら上質でリンクのような特徴を支持するか、そして、またはリンクの接続性の状態を決定するというエコー要求のときに使用されるかもしれません。
The mechanism described in this section is suitable only between the BGP speakers that are directly connected over a common virtual circuit.
このセクションで説明されたメカニズムは直接一般的な仮想のサーキットの上に接続されるBGPスピーカーだけの間で適当です。
9.1 Establishing a BGP Connection
9.1 BGP接続を確立すること。
The feature is selected by specifying zero Hold Time in the OPEN message.
特徴は、オープンメッセージでHold Timeを全く指定しないことによって、選択されます。
9.2 Circuit Manager Properties
9.2 サーキットマネージャの特性
The circuit manager must have sufficient functionality to be able to compensate for the lack of periodic KEEPALIVE messages:
サーキットマネージャには、周期的なKEEPALIVEメッセージの不足を補うことができるためには十分な機能性がなければなりません:
- It must be able to determine link layer unreachability in a
predictable finite period of a failure occurring.
- それは失敗発生の予測できる有限時代にリンクレイヤの「非-可到達性」を決定できなければなりません。
- On determining unreachability it should:
- 「非-可到達性」を決定すると、そうするべきです:
- start a configurable dead timer (comparable to a
typical Hold timer value).
- 構成可能な死んでいるタイマ(典型的なHoldタイマ価値に匹敵する)を始動してください。
- attempt to re-establish the Link Layer connection.
- Link Layer接続を復職させるのを試みてください。
- If the dead timer expires it should:
- 死んでいるタイマが期限が切れるなら、そうするべきです:
- send an internal circuit DEAD indication to TCP.
- 内部のサーキットDEAD指示をTCPに送ってください。
- If the connection is re-established it should:
- 接続が復職するなら、そうするべきです:
- cancel the dead timer.
- 死んでいるタイマを取り消してください。
- send an internal circuit UP indication to TCP.
- 内部のサーキットUP指示をTCPに送ってください。
9.3 TCP Properties
9.3 TCPの特性
A small modification must be made to TCP to process internal notifications from the circuit manager:
サーキットマネージャから内部の通知を処理するのを小さい変更をTCPにしなければなりません:
- DEAD: Flush transmit queue and abort TCP connection.
- 死者: 水洗は、待ち行列を伝えて、TCP接続を中止します。
Rekhter & Gross [Page 13] RFC 1772 BGP-4 Application March 1995
1995年のRekhterと[13ページ]総計のRFC1772BGP-4アプリケーション行進
- UP: Transmit any queued data or allow an outgoing TCP call to
proceed.
- 上がる: どんな列に並ばせられたデータも送るか、または続くという外向的なTCP要求を許してください。
9.4 Combined Properties
9.4 結合した特性
Some implementations may not be able to guarantee that the BGP process and the circuit manager will operate as a single entity; i.e. they can have a separate existence when the other has been stopped or has crashed.
いくつかの実現は、BGPの過程とサーキットマネージャが単一体として働くのを保証できないかもしれません。 もう片方が止められたか、またはクラッシュしたとき、すなわち、彼らは別々の存在を持つことができます。
If this is the case, a periodic two-way poll between the BGP process and the circuit manager should be implemented. If the BGP process discovers the circuit manager has gone away it should close all relevant TCP connections. If the circuit manager discovers the BGP process has gone away it should close all its connections associated with the BGP process and reject any further incoming connections.
これがそうであるなら、BGPの過程とサーキットマネージャの間の周期的な両用投票は実行されるべきです。 BGPの過程が、サーキットマネージャが立ち去ったと発見するなら、それはすべての関連TCP接続を終えるべきです。 サーキットマネージャが、BGPの過程が遠ざかったと発見するなら、それは、BGPの過程に関連しているすべての接続を終えて、どんなさらなる接続要求も拒絶するべきです。
10. Conclusion
10. 結論
The BGP protocol provides a high degree of control and flexibility for doing interdomain routing while enforcing policy and performance constraints and avoiding routing loops. The guidelines presented here will provide a starting point for using BGP to provide more sophisticated and manageable routing in the Internet as it grows.
方針と性能規制を実施して、輪を発送するのを避けている間、BGPプロトコルは高い統制度と柔軟性をinterdomainルーティングをするのに提供します。 ここに提示されたガイドラインは成長するとき、より洗練されて処理しやすいルーティングをインターネットに提供するのにBGPを使用するための出発点を提供するでしょう。
Rekhter & Gross [Page 14] RFC 1772 BGP-4 Application March 1995
1995年のRekhterと[14ページ]総計のRFC1772BGP-4アプリケーション行進
Appendix A. The Interaction of BGP and an IGP
付録A.はBGPとIGPの相互作用です。
This section outlines methods by which BGP can exchange routing information with an IGP. The methods outlined here are not proposed as part of the standard BGP usage at this time. These methods are outlined for information purposes only. Implementors may want to consider these methods when importing IGP information.
このセクションはBGPがルーティング情報をIGPと交換できる方法を概説します。 ここに概説された方法はこのとき、標準のBGP用法の一部として提案されません。 これらの方法は情報目的だけのために概説されています。 IGP情報を輸入するとき、作成者はこれらの方法を考えたがっているかもしれません。
This is general information that applies to any generic IGP.
これはどんな一般的なIGPにも適用される一般情報です。
Interaction between BGP and any specific IGP is outside the scope of this section. Methods for specific IGP's should be proposed in separate documents. Methods for specific IGP's could be proposed for standard usage in the future.
このセクションの範囲の外にBGPとどんな特定のIGPとの相互作用もあります。 特定のIGPのもののための方法は別々のドキュメントで提案されるべきです。 将来、標準的用法のために特定のIGPのもののための方法を提案できました。
Overview
概観
By definition, all transit AS's must be able to carry traffic which originates from and/or is destined to locations outside of that AS. This requires a certain degree of interaction and coordination between BGP and the Interior Gateway Protocol (IGP) used by that particular AS. In general, traffic originating outside of a given AS is going to pass through both interior gateways (gateways that support the IGP only) and border gateways (gateways that support both the IGP and BGP). All interior gateways receive information about external routes from one or more of the border gateways of the AS via the IGP.
定義上、すべてのトランジットASによって由来する交通は運ぶことができなければならない、そして/または、運命づけられた、そのASにおける外の位置。 これはゲートウェイプロトコル(IGP)がその特定のASで使用したBGPとInteriorの間のある度の相互作用とコーディネートを必要とします。 一般に、与えられたASの外で由来する交通は内部のゲートウェイ(IGPだけを支持するゲートウェイ)と境界ゲートウェイ(IGPとBGPの両方を支持するゲートウェイ)の両方を通り抜けるでしょう。 内部のゲートウェイが外部であることの形で情報を受け取るすべてがIGPを通して境界の1つ以上からASのゲートウェイを発送します。
Depending on the mechanism used to propagate BGP information within a given AS, special care must be taken to ensure consistency between BGP and the IGP, since changes in state are likely to propagate at different rates across the AS. There may be a time window between the moment when some border gateway (A) receives new BGP routing information which was originated from another border gateway (B) within the same AS, and the moment the IGP within this AS is capable of routing transit traffic to that border gateway (B). During that time window, either incorrect routing or "black holes" can occur.
与えられたASの中でBGP情報を伝播するのに使用されるメカニズムによって、BGPとIGPの間の一貫性を確実にするために特別な注意を払わなければなりません、状態の変化がASの向こう側に異なった速度で伝播しそうであるので。 ある境界ゲートウェイ(A)が同じASの中にもう1境界門(B)から溯源された新しいBGPルーティング情報を受け取って、このASの中のIGPはルーティングトランジット交通ができる瞬間をその境界ゲートウェイ(B)に受け取る瞬間の間には、タイムウィンドウがあるかもしれません。 そのタイムウィンドウの間、不正確なルーティングか「ブラックホール」のどちらかが起こることができます。
In order to minimize such routing problems, border gateway (A) should not advertise to any of its external peers a route to some set of exterior destinations associated with a given address prefix X via border gateway (B) until all the interior gateways within the AS are ready to route traffic destined to these destinations via the correct exit border gateway (B). In other words, interior routing should converge on the proper exit gateway before/advertising routes via that exit gateway to external peers.
そのようなルーティング問題を最小にするために、ASの中のすべての内部のゲートウェイが正しい出口境界ゲートウェイ(B)を通してこれらの目的地に運命づけられた交通を発送する準備ができるまで、境界ゲートウェイ(A)は境界ゲートウェイ(B)を通して与えられたアドレス接頭語Xに関連している外の目的地の何らかのセットへのルートの外部の同輩のいずれにも広告を出すはずがありません。 言い換えれば、内部のルーティングは外部の同輩へのその出口ゲートウェイを通して/広告ルートの前で適切な出口ゲートウェイに集まるべきです。
Rekhter & Gross [Page 15] RFC 1772 BGP-4 Application March 1995
1995年のRekhterと[15ページ]総計のRFC1772BGP-4アプリケーション行進
A.2 Methods for Achieving Stable Interactions
安定した相互作用を達成するためのA.2方法
The following discussion outlines several techniques capable of achieving stable interactions between BGP and the IGP within an Autonomous System.
以下の議論はAutonomous Systemの中でBGPとIGPとの安定した相互作用を達成できるいくつかのテクニックについて概説します。
A.2.1 Propagation of BGP Information via the IGP
IGPを通したBGP情報のA.2.1伝播
While BGP can provide its own mechanism for carrying BGP information within an AS, one can also use an IGP to transport this information, as long as the IGP supports complete flooding of routing information (providing the mechanism to distribute the BGP information) and one pass convergence (making the mechanism effectively atomic). If an IGP is used to carry BGP information, then the period of desynchronization described earlier does not occur at all, since BGP information propagates within the AS synchronously with the IGP, and the IGP converges more or less simultaneously with the arrival of the new routing information. Note that the IGP only carries BGP information and should not interpret or process this information.
また、BGPがASの中でBGP情報を運ぶのにそれ自身のメカニズムを提供できる間、1つはこの情報を輸送するのにIGPを使用できます、IGPがルーティング情報(BGP情報を分配するためにメカニズムを提供する)と1つのパス集合の完全な氾濫を支持する(メカニズムを事実上、原子にして)限り。 IGPがBGP情報を運ぶのに使用されるなら、より早く説明された脱同期化の期間は全く起こりません、BGP情報がIGPと共にASの中で同時伝播されて、IGPが同時に新しいルーティング情報の到着で多少一点に集まるので。 IGPだけがこの情報をBGP情報を運んで、解釈するはずがありませんし、また処理するはずがないことに注意してください。
A.2.2 Tagged Interior Gateway Protocol
A.2.2は内部のゲートウェイプロトコルにタグ付けをしました。
Certain IGPs can tag routes exterior to an AS with the identity of their exit points while propagating them within the AS. Each border gateway should use identical tags for announcing exterior routing information (received via BGP) both into the IGP and when propagating this information to other internal peers (peers within the same AS). Tags generated by a border gateway must uniquely identify that particular border gateway--different border gateways must use different tags.
あるIGPsはASの中でそれらを伝播している間、ASへの外のルートに彼らのエキジットポイントのアイデンティティをタグ付けできます。 それぞれの境界ゲートウェイは、IGPとこの情報を他に内部であることで伝播するのがいつじっと見るかまで(同じASの中の同輩)外のルーティング情報(BGPを通して、受信する)を発表するのに同じタグを使用するはずです。 境界ゲートウェイで発生するタグは唯一その特定の境界ゲートウェイを特定しなければなりません--異なった境界ゲートウェイは異なったタグを使用しなければなりません。
All Border Gateways within a single AS must observe the following two rules:
独身のASの中のすべてのBorder Gatewaysが以下の2つの規則を守らなければなりません:
1. Information received from an internal peer by a border gateway
A declaring a set of destination associated with a given
address prefix to be unreachable must immediately be propagated
to all of the external peers of A.
1. すぐに、与えられたアドレス接頭語に関連している目的地のセットが手が届かないと宣言する境界ゲートウェイAによって内部の同輩から受け取られた情報をAの外部の同輩のすべてに伝播しなければなりません。
2. Information received from an internal peer by a border gateway
A about a set of reachable destinations associated with a given
address prefix X cannot be propagated to any of the external
peers of A unless/until A has an IGP route to the set of
destinations covered by X and both the IGP and the BGP routing
information have identical tags.
2. Aまでの/でXで目的地のセットへのIGPルートをカバーしない場合、およそ1セットの届いている目的地が与えられたアドレス接頭語Xに関連づけた境界ゲートウェイAによって内部の同輩から受け取られた情報はAの外部の同輩のどれかに伝播できません、そして、IGPとBGPルーティング情報の両方には、同じタグがあります。
These rules guarantee that no routing information is announced externally unless the IGP is capable of correctly supporting it. It
これらの規則は、IGPが正しくそれを支持できないならルーティング情報が全く外部的に発表されないのを保証します。 それ
Rekhter & Gross [Page 16] RFC 1772 BGP-4 Application March 1995
1995年のRekhterと[16ページ]総計のRFC1772BGP-4アプリケーション行進
also avoids some causes of "black holes".
また、「ブラックホール」のいくつかの原因を避けます。
One possible method for tagging BGP and IGP routes within an AS is to use the IP address of the exit border gateway announcing the exterior route into the AS. In this case the "gateway" field in the BGP UPDATE message is used as the tag.
ASの中でBGPとIGPルートにタグ付けをするための1つの可能な方法は外のルートをASに発表する出口境界ゲートウェイのIPアドレスを使用することです。 この場合、BGP UPDATEメッセージの「ゲートウェイ」分野はタグとして使用されます。
An alternate method for tagging BGP and IGP routes is to have BGP and the IGP agree on a router ID. In this case, the router ID is available to all BGP (version 3 or higher) speakers. Since this ID is already unique it can be used directly as the tag in the IGP.
BGPとIGPルートにタグ付けをするための代替方法はBGPとIGPをルータIDに同意させることです。 この場合、すべてのBGP(バージョンより多くの3)スピーカーにとって、ルータIDは利用可能です。 このIDが既にユニークであるので、直接タグとしてIGPでそれを使用できます。
A.2.3 Encapsulation
A.2.3カプセル化
Encapsulation provides the simplest (in terms of the interaction between the IGP and BGP) mechanism for carrying transit traffic across the AS. In this approach, transit traffic is encapsulated within an IP datagram addressed to the exit gateway. The only requirement imposed on the IGP by this approach is that it should be capable of supporting routing between border gateways within the same AS.
カプセル化は最も簡単な(IGPとBGPとの相互作用に関する)メカニズムをASの向こう側にトランジット交通を運ぶのに提供します。 このアプローチでは、トランジット交通は出口ゲートウェイに記述されたIPデータグラムの中に要約されます。 このアプローチでIGPに課された唯一の要件は同じASの中で境界ゲートウェイの間で掘るのを支持できるべきであるということです。
The address of the exit gateway A for some exterior destination X is specified in the BGP identifier field of the BGP OPEN message received from gateway A (via BGP) by all other border gateways within the same AS. In order to route traffic to destination X, each border gateway within the AS encapsulates it in datagrams addressed to gateway A. Gateway A then performs decapsulation and forwards the original packet to the proper gateway in another AS.
いくつかの外の目的地Xへの出口ゲートウェイAのアドレスはゲートウェイA(BGPを通した)ごとに同じASの中に受け取られたBGP OPENメッセージのBGP識別子分野で指定されます。 ASの中のそれぞれの境界ゲートウェイは、目的地Xに交通を発送するためにゲートウェイA.に記述されたデータグラムでそれを要約します。ゲートウェイAは、別のASの適切なゲートウェイに次に、被膜剥離術を実行して、オリジナルのパケットを送ります。
Since encapsulation does not rely on the IGP to carry exterior routing information, no synchronization between BGP and the IGP is required.
カプセル化が外のルーティング情報を運ぶためにIGPを当てにしないので、BGPとIGPの間の同期は全く必要ではありません。
Some means of identifying datagrams containing encapsulated IP, such as an IP protocol type code, must be defined if this method is to be used.
この方法が使用されていることであるならIPプロトコルタイプコードなどの要約のIPを含むデータグラムを特定するいくつかの手段を定義しなければなりません。
Note that, if a packet to be encapsulated has length that is very close to the MTU, that packet would be fragmented at the gateway that performs encapsulation.
要約されるべきパケットにMTUの非常に近くにある長さがあるならそのパケットがカプセル化を実行するゲートウェイで断片化されることに注意してください。
A.2.4 Pervasive BGP
A.2.4の普及しているBGP
If all routers in an AS are BGP speakers, then there is no need to have any interaction between BGP and an IGP. In such cases, all routers in the AS already have full information of all BGP routes. The IGP is then only used for routing within the AS, and no BGP
ASのすべてのルータがBGPスピーカーであるなら、BGPとIGPとのどんな相互作用も持つ必要は全くありません。 そのような場合、ASのすべてのルータには、すべてのBGPルートに関する完全情報が既にあります。 そして、IGPはASにもかかわらず、BGPの中のルーティングに使用されるだけです。
Rekhter & Gross [Page 17] RFC 1772 BGP-4 Application March 1995
1995年のRekhterと[17ページ]総計のRFC1772BGP-4アプリケーション行進
routes are imported into the IGP.
ルートをIGPに輸入します。
For routers to operate in this fashion, they must be able to perform a recursive lookup in their routing table. The first lookup will use a BGP route to establish the exit router, while the second lookup will determine the IGP path to the exit router.
ルータがこんなやり方で作動するように、それらは経路指定テーブルで再帰的なルックアップを実行できなければなりません。 最初のルックアップは出口ルータを証明するのにBGPルートを使用するでしょう、2番目のルックアップがIGP経路を出口ルータに決定するでしょうが。
Since the IGP carries no external information in this scenario, all routers in the AS will have converged as soon as all BGP speakers have new information about this route. Since there is no need to delay for the IGP to converge, an implementation may advertise these routes without further delay due to the IGP.
IGPがこのシナリオでどんな外部の情報も運ばないので、すべてのBGPスピーカーにこのルートに関する新情報があるとすぐに、ASのすべてのルータが一点に集まってしまうでしょう。 IGPが一点に集まるように延着する必要は全くないとき、IGPのため、実現はこれ以上遅れることなくこれらのルートの広告を出すかもしれません。
A.2.5 Other Cases
A.2.5他のケース
There may be AS's with IGPs which can neither carry BGP information nor tag exterior routes (e.g., RIP). In addition, encapsulation may be either infeasible or undesirable. In such situations, the following two rules must be observed:
BGP情報を運ばないで、外のルートにタグ付けをすることができないIGPs(例えば、RIP)があるASのものがあるかもしれません。 さらに、カプセル化は、実行不可能であるか、または望ましくないかもしれません。 そのような状況で、以下の2つの規則を守らなければなりません:
1. Information received from an internal peer by a border gateway
A declaring a destination to be unreachable must immediately be
propagated to all of the external peers of A.
1. すぐに、目的地が手が届かないと宣言する境界ゲートウェイAによって内部の同輩から受け取られた情報をAの外部の同輩のすべてに伝播しなければなりません。
2. Information received from an internal peer by a border gateway
A about a reachable destination X cannot be propagated to any
of the external peers of A unless A has an IGP route to X and
sufficient time has passed for the IGP routes to have
converged.
2. AがIGPルートをXに持って、十分な時間が一点に集まったようにIGPルートに適用していない場合、境界ゲートウェイAによって届いている目的地Xに関して内部の同輩から受け取られた情報はAの外部の同輩のいずれにも伝播できません。
The above rules present necessary (but not sufficient) conditions for propagating BGP routing information to other AS's. In contrast to tagged IGPs, these rules cannot ensure that interior routes to the proper exit gateways are in place before propagating the routes to other AS's.
上の規則はBGPルーティング情報を他のASに伝播するための必要で(十分でない)の状態を提示します。 タグ付けをされたIGPsと対照して、これらの規則は、他のASにルートを伝播する前に、適切な出口ゲートウェイへの内部のルートが適所にあるのを確実にすることができません。
If the convergence time of an IGP is less than some small value X, then the time window during which the IGP and BGP are unsynchronized is less than X as well, and the whole issue can be ignored at the cost of transient periods (of less than length X) of routing instability. A reasonable value for X is a matter for further study, but X should probably be less than one second.
IGPの集合時間が以下であるなら、IGPとBGPが非連動するタイムウィンドウはまた、Xより何らかの小さい値Xより少ないです、そして、一時的な期間(長さX以下の)のルーティングの不安定性の費用で全体の問題は無視できます。 Xのための適正価値はさらなる研究への問題ですが、Xはたぶん1秒未満であるべきです。
If the convergence time of an IGP cannot be ignored, a different approach is needed. Mechanisms and techniques which might be appropriate in this situation are subjects for further study.
IGPの集合時間を無視できないなら、異なるアプローチが必要です。 この状況で適切であるかもしれないメカニズムとテクニックはさらなる研究への対象です。
Rekhter & Gross [Page 18] RFC 1772 BGP-4 Application March 1995
1995年のRekhterと[18ページ]総計のRFC1772BGP-4アプリケーション行進
References
参照
[1] Rekhter Y., and T. Li, "A Border Gateway Protocol 4 (BGP-4), RFC
1771, T.J. Watson Research Center, IBM Corp., cisco Systems,
March 1995.
[1]Rekhter Y.、およびT.李、「ボーダ・ゲイトウェイ・プロトコル4(BGP-4)、RFC1771、T.J.ワトソン研究所、IBM社、コクチマスSystems、1995年3月。」
[2] Braun, H-W., "Models of Policy Based Routing", RFC 1104,
Merit/NSFNET, June 1989.
[2] ブラウン、H-W.、「方針のベースのルート設定のモデル」、RFC1104、長所/NSFNET、1989年6月。
[3] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Supernetting: an
Address Assignment and Aggregation Strategy", RFC1519, BARRNet,
cisco, MERIT, OARnet, September 1993.
[3] フラー、V.、李、T.、ユー、J.、およびK.Varadhan、「スーパーネッティング:」 「Address AssignmentとAggregation Strategy」、RFC1519、BARRNet、コクチマス、MERIT、OARnet、9月1993日
Security Considerations
セキュリティ問題
Security issues are not discussed in this memo.
このメモで安全保障問題について議論しません。
Authors' Addresses
作者のアドレス
Yakov Rekhter T.J. Watson Research Center IBM Corporation P.O. Box 704, Office H3-D40 Yorktown Heights, NY 10598
ニューヨーク ヤコフRekhter T.J.ワトソン研究所IBM社の私書箱704、オフィスH3-D40ヨークタウンの高さ、10598
Phone: +1 914 784 7361 EMail: yakov@watson.ibm.com
以下に電話をしてください。 +1 7361年の914 784メール: yakov@watson.ibm.com
Phill Gross MCI Data Services Division 2100 Reston Parkway, Room 6001, Reston, VA 22091
事業部2100レストン公園道路、部屋6001、レストン、フィルGrossのMCIデータServicesヴァージニア 22091
Phone: +1 703 715 7432 EMail: 0006423401@mcimail.com
以下に電話をしてください。 +1 7432年の703 715メール: 0006423401@mcimail.com
IETF IDR WG mailing list: bgp@ans.net To be added: bgp-request@ans.net
IETF IDR WGメーリングリスト: 加えられるべき bgp@ans.net : bgp-request@ans.net
Rekhter & Gross [Page 19]
Rekhterとグロス[19ページ]
一覧
スポンサーリンク
