RFC1164 日本語訳
1164 Application of the Border Gateway Protocol in the Internet. J.C.Honig, D. Katz, M. Mathis, Y. Rekhter, J.Y. Yu. June 1990. (Format: TXT=56278 bytes) (Obsoleted by RFC1268) (Status: HISTORIC)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group J. Honig, Cornell Univ. Theory Center
Request for Comments: 1164 D. Katz, Merit/NSFNET
M. Mathis, Pittsburgh Supercomputing Center
Y. Rekhter, T.J. Watson Research Center, IBM Corp
J. Yu, Merit/NSFNET
June 1990
ネットワークワーキンググループJ.のホニッグ、コーネル大学 コメントを求める理論センター要求: 1164 D.キャッツ、長所/NSFNET M.マシス、ピッツバーグSupercomputingはY.Rekhterを中心に置きます、T.J.ワトソン研究所、IBMのCorp J.ユー、長所/NSFNET1990年6月
Application of the Border Gateway Protocol in the Internet
インターネットでのボーダ・ゲイトウェイ・プロトコルの応用
Status of this Memo
このMemoの状態
This RFC, together with its companion RFC-1163, "A Border Gateway Protocol (BGP)", define a Proposed Standard for an inter-autonomous system routing protocol for the Internet.
仲間RFC-1163に伴う「ボーダ・ゲイトウェイ・プロトコル(BGP)」というこのRFCは相互自律システムルーティング・プロトコルのためにProposed Standardをインターネットと定義します。
This protocol, like any other at this initial stage, may undergo modifications before reaching full Internet Standard status as a result of deployment experience. Implementers are encouraged to track the progress of this or any protocol as it moves through the standardization process, and to report their own experience with the protocol.
この初期のいかなる他の、なようにも、展開経験の結果、完全なインターネットStandard状態に達する前に、このプロトコルは変更を受けるかもしれません。 Implementersは標準化過程で動くときこれかどんなプロトコルの進歩も追跡して、プロトコルのそれら自身の経験を報告するよう奨励されます。
This protocol is being considered by the Interconnectivity Working Group (IWG) of the Internet Engineering Task Force (IETF). Information about the progress of BGP can be monitored and/or reported on the IWG mailing list (IWG@nri.reston.va.us).
このプロトコルはインターネット・エンジニアリング・タスク・フォース(IETF)のInterconnectivity作業部会(IWG)によって考えられています。 IWGメーリングリスト( IWG@nri.reston.va.us )に関してBGPの進歩に関する情報をモニターされる、そして/または、報告できます。
Please refer to the latest edition of the "IAB Official Protocol Standards" RFC for current information on the state and status of standard Internet protocols.
標準のインターネットプロトコルの状態と状態に関する現行情報について「IABの公式のプロトコル標準」RFCの最新版を参照してください。
Distribution of this memo is unlimited.
このメモの分配は無制限です。
Table of Contents
目次
1. Acknowledgements....................................... 2 2. Introduction........................................... 2 3. BGP Theory and Application............................. 3 3.1 Topological Model..................................... 3 3.2 BGP in the Internet................................... 4 3.2.1 Topology Considerations............................. 4 3.2.2 Global Nature of BGP................................ 5 3.2.3 BGP Neighbor Relationships.......................... 5 3.3 Policy Making with BGP................................ 6 4. Operational Issues..................................... 7 4.1 Path Selection........................................ 7 4.2 Syntax and Semantics for BGP Configuration Files...... 9 5. The Interaction of BGP and an IGP...................... 17
1. 承認… 2 2. 序論… 2 3. BGP理論と応用… 3 3.1位相モデル… 3 インターネットの3.2BGP… 4 3.2 .1 トポロジー問題… 4 3.2 .2 BGPのグローバルなネイチャー… 5 3.2 .3 BGP隣人関係… 5 BGPとの3.3政策立案… 6 4. 操作上の問題… 7 4.1 経路選択… 7 BGP構成ファイルのための4.2の構文と意味論… 9 5. BGPとIGPの相互作用… 17
Interconnectivity Working Group [Page 1] RFC 1164 BGP - Application June 1990
相互接続性ワーキンググループ[1ページ]RFC1164BGP--アプリケーション1990年6月
5.1 Overview.............................................. 17 5.2 Methods for Achieving Stable Interactions............. 17 5.2.1 Propagation of BGP Information via the IGP.......... 18 5.2.2 Tagged Interior Gateway Protocol.................... 18 5.2.3 Encapsulation....................................... 19 5.2.4 Other Cases......................................... 19 6. Implementation Recommendations......................... 20 6.1 Multiple Networks Per Message......................... 20 6.2 Preventing Excessive Resource Utilization............. 20 6.3 Processing Messages on a Stream Protocol.............. 21 6.4 Processing Update Messages............................ 21 7. Conclusion............................................. 22 References................................................ 22 Security Considerations................................... 22 Authors' Addresses........................................ 22
5.1概観… 17 安定した相互作用を達成するための5.2の方法… 17 5.2 .1 IGPを通したBGP情報の伝播… 18 5.2 .2 内部のゲートウェイプロトコルにタグ付けをします… 18 5.2 .3カプセル化… 19 5.2 他の.4のケース… 19 6. 実現推薦… 20 6.1 複数の1メッセージあたりのネットワーク… 20 6.2 過度のリソース利用を防ぎます… 20 6.3 流れに関する処理メッセージは議定書を作ります… 21 6.4 処理アップデートメッセージ… 21 7. 結論… 22の参照箇所… 22 セキュリティ問題… 22人の作者のアドレス… 22
1. Acknowledgements
1. 承認
The authors would like to thank Guy Almes (Rice University), Kirk Lougheed (cisco Systems), Hans-Werner Braun (Merit/NSFNET), Sue Hares (Merit/NSFNET), and the Interconnectivity Working Group of the Internet Engineering Task Force (chaired by Guy Almes) for their contributions to this paper.
作者はこの紙への彼らの貢献についてガイAlmes(ライス大学)、カーク・ロッキード(コクチマスSystems)、ハンス-ヴェルナーBraun(長所/NSFNET)、スーHares(長所/NSFNET)、およびインターネット・エンジニアリング・タスク・フォースのInterconnectivity作業部会(ガイAlmesによってまとめられる)に感謝したがっています。
2. Introduction
2. 序論
The Border Gateway Protocol (BGP), described in RFC 1163, is an interdomain 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].
RFC1163で説明されたボーダ・ゲイトウェイ・プロトコル(BGP)はinterdomainルーティング・プロトコルです。 BGPを通して交換されたネットワーク可到達性情報は、ルーティング輪を検出して、RFC1104[2]に概説されているように性能好みと方針規制に基づくルーティング決定を実施するために十分な情報を提供します。
This memo uses the term "Autonomous System" throughout. 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 ASs. 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 ASs to have a single coherent interior routing plan and presents a consistent picture of what networks are reachable through it. From the standpoint of exterior routing, an AS can be viewed as monolithic: reachability to networks directly connected to the AS must be equivalent from all border gateways of the AS.
このメモはあらゆる点で「自律システム」という用語を使用します。 Autonomous Systemの古典的な定義はただ一つの技術的な管理の下で、1セットのルータです、ASの中でパケットを発送するのに内部のゲートウェイプロトコルと一般的な測定基準を使用して、他のASsにパケットを発送するのに外のゲートウェイプロトコルを使用して。 この古典的な定義が開発されて以来、独身のASがASの中でいくつかの内部のゲートウェイプロトコルと時々数セットの測定基準を使用するのは一般的になっています。 ここでのAutonomous Systemという用語の使用は、ただ一つの論理的な内部のルーティングプランを持つために、複数のIGPsと測定基準が使用されてさえいるとき、ASの管理が他のASsにおいて現れるという事実を強調して、どんなネットワークがそれを通して届いているかに関する一貫した絵を提示します。 外のルーティングの見地から、一枚岩的であるとしてASを見なすことができます: 直接ASに接続されたネットワークへの可到達性はASのすべての境界ゲートウェイから同等であるに違いありません。
Interconnectivity Working Group [Page 2] RFC 1164 BGP - Application June 1990
相互接続性ワーキンググループ[2ページ]RFC1164BGP--アプリケーション1990年6月
This paper discusses the use of BGP in the Internet environment. Issues such as topology, the interaction between BGP and IGPs, and the enforcement of policy rules with BGP will be presented.
この論文はインターネット環境におけるBGPの使用について議論します。 トポロジーなどの問題、BGPとIGPsとの相互作用、およびBGPとの政策ルールの実施は提示されるでしょう。
All of the discussions in this paper are based on the assumption that the Internet is a collection of arbitrarily connected Autonomous Systems. The AS is 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.
インターネットは任意に接続されたAutonomous Systemsの収集です。この紙における議論のすべてが少なくともシステムへのルーティング情報の表現の目的のためにASの外でただ一つの管理実体によってASが管理されると思われるという仮定に基づいています。
3. BGP Theory and Application
3. BGP理論と応用
3.1 Topological Model
3.1 位相モデル
We will be concerned throughout this paper with a general graph whose nodes are ASs and whose edges are connections between pairs of ASs. The notion of AS is discussed above in Section 2. When we say that a connection exists between two ASs, we mean both of two things:
私たちはこの紙中でノードがASsであり、縁が組のASsの間の接続である一般的なグラフに関係があるでしょう。 セクション2で上でASの概念について議論します。 接続が2ASsの間に存在すると言うとき、私たちは2つのものの両方を言っています:
physical connection: there is a shared network between the two ASs,
and on this shared network 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
resort to Inter-AS or Intra-AS routing.
物理接続: 2ASsの間には、共用回線網があります、そして、この共用回線網では、各ASは少なくとも1境界門にそのASに属させます。 したがって、それぞれのASの境界ゲートウェイはInter-ASへのリゾートもIntra-ASルーティングなしで他のASの境界ゲートウェイにパケットを送ることができます。
BGP connection: there is a BGP session between BGP speakers on each
of the ASs, and this session communicates to each connected AS
those routes through the physically connected border gateways of
the other AS that can be used for specific networks. Throughout
this document we place an additional restriction on the BGP
speakers that form the BGP connection: they must themselves share
the same network that their border gateways share. Thus, a BGP
session between the adjacent ASs 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接続: それぞれのASsの上のBGPスピーカーの間には、BGPセッションがあります、そして、このセッションは特定のネットワークに使用できる他のASの物理的に接続された境界ゲートウェイを通してそれぞれの接続ASにそれらのルートを伝えます。 このドキュメント中では、私たちはBGP接続を形成するBGPスピーカーに関して追加制限を課します: そうしなければならない、自分たち、それらの境界ゲートウェイが共有するのと同じネットワークを共有してください。 したがって、隣接しているASsの間のBGPセッションはInter-ASかIntra-ASルーティングのどちらかからサポートを全く必要としません。 この制限に一致していないケースはこのドキュメントの範囲をそらせます。
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 network. Only the AS's border gateways on the connection's shared network may be used by that AS's BGP speakers on that shared network in NEXT_HOP attributes in Update messages. 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 connection. In all BGP usage, we intend that the flow of packets from one AS to the other correspond to advertised AS paths.
したがって、各接続のときに、各ASには1人以上のBGPスピーカーと1境界門以上があります、そして、これらのBGPスピーカーと境界ゲートウェイは共用回線網にすべて位置しています。 そのASのBGPスピーカーはその共用回線網でUpdateメッセージのネクスト_HOP属性に接続の共用回線網のASの境界ゲートウェイだけを使用してもよいです。 同じ接続のときにそれぞれの他のASの境界ゲートウェイに可能になるように1ASのBGPスピーカーによって与えられた接続に発表された経路を取ります。 すべてのBGP用法で、私たちは、パケットの1ASからもう片方までの流れが広告を出しているAS経路に対応することを意図します。
Much of the traffic carried within an AS either originates or
またはASの中で運ばれた交通の大部分が由来する。
Interconnectivity Working Group [Page 3] RFC 1164 BGP - Application June 1990
相互接続性ワーキンググループ[3ページ]RFC1164BGP--アプリケーション1990年6月
terminates at that AS (i.e., either the source IP address or the destination IP address of the IP packet identifies a host on a network directly connected 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(すなわち、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 another AS.
Naturally, a stub AS only carries local traffic.
ASを引き抜いてください: 別のASに単独結合しか持っていないAS。 当然、スタッブASはローカルの交通を運ぶだけです。
multihomed AS: an AS that has more than one connection to other ASs,
but refuses to carry transit traffic.
multihomed AS: 他のASsには1つ以上の接続がありますが、トランジット交通を運ぶのを拒否するAS。
transit AS: an AS that has more than one connection to other ASs and
is designed (under certain policy restrictions) to carry both
transit and local traffic.
トランジットAS: 他のASsには1つ以上の接続があって、トランジットとローカルの交通の両方を運ぶように設計されている(ある方針制限で)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 ASs.
完全なAS経路がルーティング輪を抑圧する効率的で簡単な方法を提供して、いくつかの距離ベクトルアルゴリズムに関連している「無限カウント」問題を解決するので、BGPはASsのインタコネクトにどんな位相的な制限も課しません。
3.2 BGP in the Internet
3.2 インターネットのBGP
3.2.1 Topology Considerations
3.2.1 トポロジー問題
The overall Internet topology may be viewed as an arbitrary interconnection of transit, multihomed, and stub ASs. In order to minimize the impact on the current Internet infrastructure, stub and multihomed ASs need not use BGP. These ASs may run other protocols (e.g., EGP) to exchange reachability information with transit ASs. Transit ASs then tag this information as having been learned via EGP or some other method. The fact that BGP need not run on stub or multihomed ASs has no negative impact on the overall quality of inter-AS routing for traffic not local to the stub or multihomed ASs in question.
総合的なインターネットトポロジーは、「マルチ-家へ帰」ったトランジットの任意のインタコネクトとして見なされて、ASsを引き抜くかもしれません。 現在のインターネット基盤への影響を最小にするために、スタッブとmultihomed ASsはBGPを使用する必要はありません。 これらのASsは、トランジットASsと可到達性情報を交換するために、他のプロトコル(例えば、EGP)を走らせるかもしれません。 そして、トランジットASsはEGPかある他の方法で学習されたとしてこの情報にタグ付けをします。 BGPがスタッブかmultihomed ASsの上で作業する必要はないという事実で、負の衝撃は全く交通のための相互ASルーティングの総合的な品質にスタッブか問題のmultihomed ASsに地方になりません。
Of course, BGP may be used for stub and multihomed ASs as well, providing advantage in bandwidth and performance over some of the currently used protocols (such as EGP). In addition, this would result in less need for the use of defaults and in better choices of Inter-AS routes for mulitihomed ASs.
もちろん、BGPはまた、スタッブとmultihomed ASsに使用されるかもしれません、現在中古のプロトコル(EGPなどの)のいくつか上で帯域幅と性能に利点を提供して。 さらに、これはデフォルトの使用とInter-ASルートの、より良い選択における、mulitihomed ASsの、より少ない必要性をもたらすでしょう。
Interconnectivity Working Group [Page 4] RFC 1164 BGP - Application June 1990
相互接続性ワーキンググループ[4ページ]RFC1164BGP--アプリケーション1990年6月
3.2.2 Global Nature of BGP
3.2.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___としての___
This diagram points out that, while BGP alone carries information between ASs, a combination of BGP and an IGP carries 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 this paper.
このダイヤグラムは、BGPだけがASsの間まで情報を運びますが、BGPとIGPの組み合わせがASの向こう側に情報を運ぶと指摘します。 ASの中のBGPとIGPの間のルーティング情報について一貫性があることを保証するのと、重要な問題であり、後で十分この紙で議論します。
3.2.3 BGP Neighbor Relationships
3.2.3 BGP隣人関係
As discussed in the introduction, the Internet is viewed as a set of arbitrarily connected Autonomous Systems (ASs). BGP gateways in each AS communicate with each other to exchange network reachability information based on a set of policies established within each AS. Computers that communicate directly with each other via BGP are known as BGP neighbors. BGP neighbors can be located within the same AS or in different ASs. For the sake of discussion, BGP communications with neighbors in different ASs will be referred to as External BGP, and with neighbors in the same AS as Internal BGP.
序論で議論するように、インターネットは任意に接続されたAutonomous Systems(ASs)の1セットとして見なされます。 各ASのBGPゲートウェイは各ASの中で確立された1セットの方針に基づく交換網可到達性情報に互いと交信します。 互いと共にBGPを通して直接伝達するコンピュータはBGP隣人として知られています。 BGP隣人は同じAS以内か異なったASsに位置できます。 議論のために、異なったASsの隣人とのBGPコミュニケーションはExternal BGP、およびInternal BGPと同じASの隣人と共に示されるでしょう。
External BGP In the case of External BGP, the BGP neighbors must
belong to different ASs, but share a common network. This common
network 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.
外部のBGP In、External BGPに関するケース、BGP隣人は異なったASsに属さなければなりませんが、一般的なネットワークを共有してください。 この一般的なネットワークは、BGPメッセージをそれらに伝えるのに使用されるべきです。 介入しているASの向こう側のBGPの使用はAS経路情報を無効にします。 BGPスピーカーがどのAutonomous Systemに属すかを指定するのにBGPと共にAutonomous System番号を使用しなければなりません。
Internal BGP There can be as many BGP gateways as deemed necessary
within an AS. Usually, if an AS has multiple connections to other
ASs, multiple BGP gateways are needed. All BGP gateways
representing the same AS must give a consistent image of the AS to
the outside. This requires that the BGP gateways 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 gateways within an AS must be consistent.
内部のBGP ThereはASの中で必要であると考えられるのと同じくらい多くのBGPゲートウェイであるかもしれません。 通常、他のASsにASが複数の接続がいるなら、複数のBGPゲートウェイが必要です。 同じASを表すと外部へのASの一貫したイメージが与えられなければならないすべてのBGPゲートウェイ。 これは、BGPゲートウェイの中に一貫したルーティング情報があるのを必要とします。 これらのゲートウェイはBGPを通して他の手段で互いと交信できます。 ASの中のすべてのBGPゲートウェイに適用された方針規制は一貫しているに違いありません。
Interconnectivity Working Group [Page 5] RFC 1164 BGP - Application June 1990
相互接続性ワーキンググループ[5ページ]RFC1164BGP--アプリケーション1990年6月
3.3 Policy Making with BGP
3.3 BGPとの政策立案
BGP provides the capability of enforcing some policies based on various preferences and constraints. Policies are determined by the AS administration and are provided to BGP in the form of configuration information. These policies are enforced within a BGP speaker by affecting the selection of paths from multiple alternatives, and by controlling the redistribution of routing information. Policies are not directly encoded in the protocol.
BGPは様々な好みと規制に基づくいくつかの方針を実施する能力を提供します。 方針をAS管理によって決定されて、設定情報の形でBGPに提供します。 これらの方針は、BGPスピーカーの中で複数の選択肢から経路の品揃えに影響して、ルーティング情報の再分配を制御することによって、励行されます。 方針はプロトコルで直接コード化されません。
Non-technical constraints 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 examples of non-technical constraints 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
ASs. (It does so by not advertising routes to networks other
than those directly connected to it.)
1. multihomed ASは、他のASsのためのトランジットASとして機能するのを拒否できます。 (それは直接それに接続されたもの以外のネットワークにルートの広告を出さないことによって、そうします。)
2. A multihomed AS can become a transit AS by allowing a certain
set of ASs to use it as such. (It does so by advertising
routes to networks to this set of ASs.)
2. ASsのあるセットがそういうものとしてそれを使用するのを許容することによって、multihomed ASはトランジットASになることができます。 (それは広告ルートでそうASsのこのセットへのネットワークにします。)
3. An AS can favor or disfavor the use of certain ASs for carrying
transit traffic from itself to networks advertised with
competing AS paths.
3. ASはあるASsのそれ自体から競争している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 ASs. (Shorter AS
paths can be preferred over longer ones.)
1. ASはトランジットASsの数を最小にすることができます。 (より長いものより短いAS経路を好むことができます。)
2. The quality of transit ASs. If an AS determines, using BGP,
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 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.
2. トランジットASsの品質。 BGPを使用して、ASがその2を決定するか、または与えられた目的地に達するのにより多くのAS経路を使用できるなら、そのASはそれが候補AS道のどれを使用するかを決めるさまざまな手段を使用できます。 操作の直径、リンク速度、容量、混雑するようになる傾向、および品質のようなものはASの品質を測定できます。 これらの品質に関する情報はBGP以外の手段で決定するかもしれません。
3. Preference of internal routes over external routes.
3. 外部経路の上の内部のルートの好み。
Non-technical policy will typically override performance issues.
非技術系の方針は性能問題を通常くつがえすでしょう。
For consistency, combinations of policies and route selection
一貫性、方針とルート選択の組み合わせのために
Interconnectivity Working Group [Page 6] RFC 1164 BGP - Application June 1990
相互接続性ワーキンググループ[6ページ]RFC1164BGP--アプリケーション1990年6月
procedures that might result in equal cost paths must be resolved in a deterministic fashion.
決定論的なファッションで等しい費用経路をもたらすかもしれない手順を決議しなければなりません。
Fundamental to BGP usage is the rule that an AS advertizes to its neighboring ASs only those routes that it uses. This rule reflects the "hop-by-hop" routing paradigm generally used by the current Internet. Note that some policies that cannot be supported by the "hop-by-hop" routing paradigm and which require such techniques as source routing to enforce. For example, BGP does not enable one AS to send traffic to a neighbor AS intending that that traffic take a different route from that taken by traffic originating in the neighbor AS. On the other hand, BGP can support any policy conforming to the "hop-by-hop" routing paradigm. Since the current Internet uses only the "hop-by-hop" routing paradigm and since BGP can support any policy that conforms to that paradigm, BGP is highly applicable as an inter-AS routing protocol for the current Internet.
BGP用法への基本的はAS advertizesが隣接しているASs唯一のそれらにそれを発送するという規則です。それは使用します。 この規則は一般に、現在のインターネットによって使用される「ホップごとの」ルーティングパラダイムを反映します。 そうすることができないいくつかの方針が「ホップごとの」ルーティングパラダイムによって支持されるという実施するソースルーティングのようなテクニックを必要とするメモ。 例えば、BGPは、1ASがその交通が隣人ASで起こる交通で取られたそれと異なったルートを取ることを意図する隣人ASに交通を送るのを可能にしません。 他方では、BGPは「ホップごとの」ルーティングパラダイムに従うどんな方針も支持できます。 現在のインターネットが「ホップごとの」ルーティングパラダイムだけを使用して、BGPがそのパラダイムに従うどんな方針も支持できるので、BGPは現在のインターネットへの相互ASルーティング・プロトコルとして非常に適切です。
4. Operational Issues
4. 操作上の問題
4.1 Path Selection
4.1 経路選択
One of the major tasks of a BGP speaker for a given AS at a given connection is to evaluate different paths to a destination network from its border gateways at that connection, select the best one, and then advertise it to all of its BGP neighbors at that same connection (subject to policy constraints). The key issue is how different paths are evaluated and compared.
与えられた接続の与えられたASのためのBGPスピーカーの主タスクの1つは、その同じ接続(方針規制を条件とした)のときにBGP隣人のすべてにその接続のときに境界ゲートウェイと異なった経路を送信先ネットワークに評価して、最も良い方を選択して、次に、それの広告を出すことです。 主要な問題は異なった経路がどう評価されて、比較されるかということです。
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 ASs that can be used to evaluate external paths. Rather, each AS may have its own set of criteria for path evaluation.
伝統的な距離ベクトルプロトコル(例えば、RIP)には、1つしかメートル法であることで(例えば、カウントを飛び越します)ありません。経路に関連しています。 そういうものとして、異なった経路の比較は単に2つの番号を比較するのに抑えられます。 Inter-ASルーティングにおける複雑さは外部の経路を評価するのに使用できるASsの中で一般にメートル法で同意されたaの不足から起こります。 むしろ、各ASには、それ自身の経路評価の評価基準のセットがあるかもしれません。
A BGP speaker within an Autonomous System builds a routing database consisting of the set of all feasible paths and the list of networks reachable through each path. In an efficient implementation, it will be important to store and process these paths and bundle the networks reachable through them. For purposes of precise discussion, however, it's useful to consider the set of feasible paths for a given destination network. In most cases, we would expect to find only one feasible path in the set. This will often, however, not be the case. All feasible paths must be maintained, and their maintenance speeds adaptation to the loss of the primary path, but only the primary path at any given time will ever be advertised.
Autonomous Systemの中のBGPスピーカーはすべての実行可能経路のセットと各経路を通して届いているネットワークのリストから成るルーティングデータベースを築き上げます。 効率的な実現では、それは、店に重要であり、これらの経路を処理して、それらを通して届いているネットワークを束ねるでしょう。 しかしながら、正確な議論の目的に、与えられた送信先ネットワークのために実行可能経路のセットを考えるのは役に立ちます。 多くの場合、私たちは、セットで1つの実行可能経路だけを見つけると予想するでしょう。 しかしながら、これはしばしばそうになるというわけではないでしょう。 すべての実行可能経路を維持しなければなりません、そして、彼らの維持は第一の経路の損失への適合を促進しますが、今までに、その時々で第一の経路だけの広告を出すでしょう。
Interconnectivity Working Group [Page 7] RFC 1164 BGP - Application June 1990
相互接続性ワーキンググループ[7ページ]RFC1164BGP--アプリケーション1990年6月
The path selection process can be formalized by defining a partial order over the set of all possible paths to a given destination network. One way to define this partial 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経路を写像する機能を定義することです。 そして、経路選択はこの機能をすべての実行可能経路に適用して、最も高度の好みでものを選ぶのに抑えられます。
In actual BGP implementations, criteria for assigning degree of preferences to a path can be specified in a configuration file.
実際の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.
2. BGPの範囲の外で完全なAS経路と情報から得ることができる情報の組み合わせ。
The criteria used to assign a degree of preference to a path can be classified as primitive or compound. Possible primitive criteria include:
基関数か化合物として1段階の好みを経路に割り当てるのに使用される評価基準は分類できます。 可能な原始の評価基準は:
- AS count. Paths with a smaller AS count are generally better.
- ASは数えます。 一般に、より小さいASカウントがある経路は、より良いです。
- Presence or absence of a certain AS or ASs 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 ASs and may try to avoid or prefer
them.
- 経路のあるASかASsの存在か不在。 BGPの範囲の外の情報によって、ASは彼らをあるASsのいくつかの性能の特性(例えば、帯域幅、MTU、イントラAS直径)を知って、避けようとするか、または好もうとするかもしれません。
- Path origin. A path whose endpoint is internal to the last AS
on the path (BGP is used over the entire 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.
- 力学をリンクしてください。 安定路線は不安定なものより好まれるべきです。 不要なルート変動を引き起こすのを避ける非常に慎重な方法でこの評価基準を使用しなければならないことに注意してください。 一般に、動的情報に依存するどんな評価基準も、ルーティングの不安定性を引き起こすかもしれなくて、非常に慎重に扱われるべきです。
- Policy consideration. BGP supports policy based routing based
- 方針の考慮。 BGPはベースのルーティングが基礎づけた方針を支持します。
Interconnectivity Working Group [Page 8] RFC 1164 BGP - Application June 1990
相互接続性ワーキンググループ[8ページ]RFC1164BGP--アプリケーション1990年6月
on the policy based distribution of routing information defined
in RFC 1104 [2]. A BGP gateway 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.
方針では、ルーティング情報のベースの分配はRFCで1104[2]を定義しました。 BGPゲートウェイは、いくつかの方針規制を意識していて(それ自身のASの中、外)、適切な経路選択をするかもしれません。 方針要件に従わない経路がさらに考えられません。
Metrics based on compound criteria can be computed as a weighted combination of the degree of preferences of primitive criteria. The use of compound criteria should be done with extreme caution since it involves comparing potentially uncomparable quantities.
原始の評価基準の好みの度合いの荷重している組み合わせとして合成評価基準に基づく測定基準は計算できます。 細心の注意を払って潜在的に非匹敵量を比較することを伴うので、合成評価基準を使用するべきです。
4.2 Syntax and Semantics for BGP Configuration Files
BGP構成ファイルのための4.2構文と意味論
A major task in using BGP is thus to assign a degree of preference to each available AS-path. This degree of preference will generally be a function of the number of ASs in the path, properties of the specific ASs in the path, the origin of the route, and properties of the specific border router to be used in the first hop. In this section we consider how a network administrator might articulate this function by means of a configuration file. In the future, we can imagine using tools based on network management protocols such as SNMP for this task, but the protocols do not currently support this ability.
その結果、使用BGPの主タスクはそうです。それぞれの利用可能なAS-経路に1段階の好みを割り当てるために。 一般に、この度の好みは経路のASsの数、経路の特定のASsの特性、ルートの起源、および最初のホップで使用されるべき特定の境界ルータの特性の機能になるでしょう。 このセクションでは、私たちは、ネットワーク管理者が構成ファイルによってどのようにこの機能について明確に話すかもしれないかを考えます。 将来、私たちは、このタスクのためのSNMPなどのネットワーク管理プロトコルに基づくツールを使用すると想像できますが、プロトコルは現在、この能力を支持しません。
In addition to controlling the selection of the best path to a given network, the network administrator must control the advertisement of this best path to neighboring ASs. Therefore, path selection and path distribution emerge as the two key aspects of policy expression in BGP usage.
最も良い経路の選択を与えられたネットワークに制御することに加えて、ネットワーク管理者はこの最も良い経路の広告を隣接しているASsに制御しなければなりません。 したがって、経路選択と経路分配はBGP用法による方針表現の2つの特徴として現れます。
Since different aspects of one AS's policy interact, and since the policies of different ASs interact, it is important to facilitate the analysis of such interactions by means of high-quality and consistent tools.
1ASの方針の異なった局面が相互作用して、異なったASsの方針が相互作用するので、高品質で一貫したツールによってそのような相互作用の分析を容易にするのは重要です。
There is also a need for tools to translate the expression of the network administrator's policy to some technical mechanism within a BGP speaker to implement that policy.
また、その政策を実施するために、BGPスピーカーの中にネットワークアドミニストレータの方針の表現を何らかの技術的機構に翻訳するツールの必要があります。
These factors suggest that there should be a globally consistent way of describing policies in the configuration file. The syntax and semantics of these policies should be capable of expressing the path selection phase within the local AS as well as the path redistribution phase to other ASs.
これらの要素は、構成ファイルには方針を説明するグローバルに一貫した方法があるべきであると示唆します。 これらの方針の構文と意味論は他のASsへの経路再分配フェーズと同様に地方のASの中で経路選択段階を言い表すことができるべきです。
Because it may be desirable to coordinate routing policy at an external level, it may prove worthwhile to create a language to describe this information in a globally consistent way. Policies
外部のレベルでルーティング方針を調整するのが望ましいかもしれないので、グローバルに一貫した方法でこの情報について説明するために言語を作成するのが価値があると判明するかもしれません。 方針
Interconnectivity Working Group [Page 9] RFC 1164 BGP - Application June 1990
相互接続性ワーキンググループ[9ページ]RFC1164BGP--アプリケーション1990年6月
expressed in such a language could conceivably be used by some high- level tools to analyze the interaction among the routing policies of different Autonomous Systems.
そのようなもので言い表されて、異なったAutonomous Systemsのルーティング方針の中で相互作用を分析するいくつかの高値レベルツールは多分言語を使用できました。
The following defines one possible syntax and semantics for describing AS path policies from the point of view of the local AS. Alternative syntaxes with equivalent richness of functionality are not precluded. Other mechanisms may be needed to provide a fully functional configuration language.
以下は、地方のASの観点からAS経路方針を説明するために1つの可能な構文と意味論を定義します。 機能性の同等な豊かがある代替の構文は排除されません。 他のメカニズムが完全に機能的な構成言語を提供するのが必要であるかもしれません。
A complete AS path, supplied by BGP, provides the most important mechanism for policy enforcement. Assigning a degree of preference to a particular AS path can be modelled as a matching between this path and one or more predefined AS path patterns. Each predefined AS path pattern has a degree of preference that will be assigned to any AS path that matches it.
BGPによって供給された完全なAS経路は最も重要なメカニズムを方針実施に提供します。 この経路と1の間で合っているか、またはもう少し事前に定義されたAS経路が型に基づいて作るとき、1段階の好みを特定のAS経路に割り当てるのをモデル化できます。 それぞれの事前に定義されたAS経路パターンには、それに合っているどんなAS経路にも割り当てられる1段階の好みがあります。
Since patterns are naturally expressed by regular expressions, one can use regular expressions over the alphabet of AS numbers to define AS path patterns and, therefore, to formulate policies.
パターンが正規表現で自然に言い表されるので、1つがAS経路パターンを定義するのにAS番号の基本の正規表現を使用できる、そして、したがって、方針を定式化します。
Since certain constructs occur frequently in regular expressions, the following notational shorthand (operators) is defined:
ある構造物が正規表現で頻出するので、以下の記号法の速記(オペレータ)は定義されます:
. matches any AS number. To improve readability, "." can be
replaced by "any" so long as this does not introduce ambiguity.
. どんなAS番号も合わせます。 「読み易さを改良するために」. 」 これがあいまいさを導入しない限り、「いずれも」に取り替えることができます。
* a regular expression followed by * means zero or more
repetitions
* *手段ゼロか、より多くの反復があとに続いた正規表現
+ a regular expression followed by + means one or more
repetitions
+ + 手段1か、より多くの反復があとに続いた正規表現
? a regular expression followed by ? means zero or one repetition
手段ゼロか1つの反復があとに続いた正規表現
| alternation
| 交互
() parentheses group subexpressions--an operator, such as * or
works on a single element or on a regular expression enclosed
in parentheses
()括弧グループ「副-表現」--ただ一つの要素の上の*か作品か括弧に同封された正規表現でのオペレータ
{m,n} a regular expression followed by {m,n} (where m and n are
both non-negative integers and m <= n) means at least m and at
most n repetitions.
m、正規表現がm、n続いたnは少なくともmと高々n反復しか意味しません(mとnが非負の整数とm<の両方=nであるところ)。
{m} a regular expression followed by {m} (where m is a positive
integer) means exactly m repetitions.
正規表現がm(mが正の整数であるところ)続いたmはまさにm反復を意味します。
Interconnectivity Working Group [Page 10] RFC 1164 BGP - Application June 1990
相互接続性ワーキンググループ[10ページ]RFC1164BGP--アプリケーション1990年6月
{m,} a regular expression followed by {m,} (where m is a positive
integer) means m or more repetitions.
正規表現がm続いた(mが正の整数であるところ)mはmか、より多くの反復を意味します。
Any regular expression is generated by these rules.
どんな正規表現もこれらの規則で発生します。
The Policy Based Routing Language can then be defined as follows:
次に、以下の通りPolicy Basedルート設定Languageを定義できます:
<Policy-Based-Routing> ::= { <policy-statement> }
<の方針ベースのルート設定>:、:= <施政方針>。
Semantics: each policy statement might cause a given possible BGP
advertisement (possibility) to be installed into the routing table
as the route to a given (set of) networks. Thus, an empty
Policy-Based-Routing means that no possibilities will be accepted.
意味論: 各施政方針で、与えられた(セットされる)ネットワークへのルートとして与えられた可能なBGP広告(可能性)を経路指定テーブルにインストールするかもしれません。 したがって、空のPolicyベースのルート設定は、可能性が全く受け入れられないことを意味します。
<policy-statement> ::=
<policy-expression> '=' <dop-expression> ';'
<施政方針>:、:= '<方針表現>は''<dop-表現>と等しいです''
Semantics: if a given possibility matches the policy-expression,
then that possibility will be accepted with a degree of preference
denoted by the integer value dop-expression.
意味論: 与えられた可能性が方針表現に合っていると、1段階の好みが整数値のdop-表現で指示されている状態で、その可能性を受け入れるでしょう。
<policy-expression> ::=
<policy-term> |
<policy-term> <policy-operator> <policy-term>
<方針表現>:、:= <方針用語>。| <方針><方針オペレータ><方針用語>用語
<policy-term> ::=
<network-list> <AS-path> <origin> <distribution-list> |
'(' <policy-expression> ')' |
NOT <policy-expression> |
<>
<方針用語>:、:= 経路><起源><発送先リストとしてのリスト><をネットワークでつないでいる<>。| '('<方針表現>')'| <方針表現>でない| <>。
<policy-operator> ::= OR | AND
<方針オペレータ>:、:= OR| AND
Semantics: the intersection of the network list of a possibility
and the network-list must be non-empty; the AS-path of the
possibility must match the AS-path as a sequence; the origin of
the possibility must be a member of the origin set; if these
conditions are met, the route denoted by the possibility is
accepted as a possible route to those networks of the intersection
of the possibility network list and the network-list.
意味論: 可能性のネットワークリストとネットワークリストの交差点は非人影がないに違いありません。 可能性のAS-経路は系列としてAS-経路に合わなければなりません。 可能性の起源は起源セットのメンバーであるに違いありません。 これらの条件が満たされるなら、可能性によって指示されたルートは可能なルートとして可能性ネットワークリストとネットワークリストの交差点のそれらのネットワークに認められます。
<AS-path> ::= "regular expression over AS numbers"
経路>としての<:、:= 「AS番号の上正規表現」
Semantics: the AS-path of the possibility must be generated by the
regular expression <AS-path>.
意味論: 可能性のAS-経路は正規表現<AS-経路>によって発生しなければなりません。
Interconnectivity Working Group [Page 11] RFC 1164 BGP - Application June 1990
相互接続性ワーキンググループ[11ページ]RFC1164BGP--アプリケーション1990年6月
<network-list> ::= '<' { network network-list } '>' |
'<' ANY '>'
<ネットワークリスト>:、:= '<'ネットワークネットワークリスト'>'| ''少しも'という<>'
Semantics: A non-empty sequence enumerates the network numbers of
the network-list; ANY denotes the set of all network numbers.
意味論: 非空の系列はネットワークリストのネットワーク・ナンバーを列挙します。 いずれもすべてのネットワーク・ナンバーのセットを指示します。
<origin> ::= IGP | EGP | INCOMPLETE | ANY
<の起源>:、:= IGP| EGP| 不完全| 少しも
Semantics: origin enumerates the sequence of acceptable origins;
ANY denotes the set of all origins.
意味論: 起源は許容できる起源の系列を列挙します。 いずれもすべての起源のセットを指示します。
<distribution-list> ::= '<' { AS } '>' |
'<' ANY '>'
<発送先リスト>:、:= '<'、'>'| ''少しも'という<>'
Semantics: if a given possibility as accepted and installed into
the routing table, then distribution-list is the set of
(neighboring) autonomous systems to whose border routers we will
distribute the BGP-derived routes.
意味論: そして、与えられた可能性であるなら、受け入れられて、経路指定テーブルにインストールされるように、発送先リストは私たちがBGPによって派生させられたルートを境界ルータに分配するつもりである(隣接する)の自律システムのセットです。
<dop-expression> ::= <dop-term> |
<dop-term> '+' <dop-term> |
<dop-term> '-' <dop-term> |
<dop-term> '*' <dop-term> |
<dop-term> '/' <dop-term> |
REJECT
<dop-表現>:、:= <dop-用語>。| <>'+'<dop-用語>dop-用語| <>'--'<dop-用語>dop-用語| <>'*'<dop-用語>dop-用語| <'>'/'<dop-用語>dop-用語| 廃棄物
<dop-term> ::= <integer> |
<function> |
'(' <dop-expression> ')'
<dop-用語>:、:= <整数>。| <機能>。| '('<dop-表現>')'
Semantics: if a possibility matches with degree of preference
REJECT, then that possibility will not be used. Otherwise, the
integer value of the degree of preference indicates the degree of
preference of the possibility, with higher values preferred over
lower ones.
意味論: 可能性が好みのREJECTの程度に合わせると、その可能性は使用されないでしょう。 さもなければ、好みの度合いの整数値は可能性の好みの度合いを示します、下側のものより高い値が好まれている状態で。
White spaces can be used between symbols to improve readability. "<>" denotes the empty sequence.
読み易さを改良するのにシンボルの間で余白を使用できます。 「<>」は空の系列を指示します。
There are two built-in functions, PathLength() and PathWeight(). PathLength() takes the AS path as an argument and returns the number of ASs in that path. PathWeight() takes the AS path and an AS weight table as arguments and returns the sum of weights of the ASs in the AS path as defined by the AS weight table. In order to preserve determinism, the AS weight table must always have a default weight which will be assigned to any AS which is not in that table.
2つの組込み関数、PathLength()、およびPathWeight()があります。 PathLength()は議論としてAS経路をみなして、その経路でASsの数を返します。 PathWeight()は議論としてAS経路とAS重さのテーブルをみなして、AS重さのテーブルによって定義されるようにAS経路でASsの重りの合計を返します。 決定論を保存するために、AS重さのテーブルはいつもそのテーブルにない少しのASにも割り当てられるデフォルト重りを持たなければなりません。
The AS path, as used above, is constructed from right to left which
経路が中古の上として構成されるASは左にどれを正すか。
Interconnectivity Working Group [Page 12] RFC 1164 BGP - Application June 1990
相互接続性ワーキンググループ[12ページ]RFC1164BGP--アプリケーション1990年6月
is consistent with BGP), so that the most recent AS in the path occupies the leftmost position.
BGPと一致している、)、それで、経路のその最新のASは一番左位置を占めます。
Each network (and its associated complete AS path) received from other BGP neighbors is matched against local Routing Policies.
他のBGP隣人から受け取られた各ネットワーク(そして、関連完全なAS経路)は地方のルート設定Policiesに取り組まされます。
If either no match occurs or the degree of preference associated with the matched policy is REJECT, then the received information is rejected. Otherwise, a degree of preference associated with the matched policy is assigned to that path. Notice that the process terminates on the first successful match. Therefore, policy-terms should be ordered from more specific to more general.
マッチが全く現れないか、取り組んでいる方針に関連している好みの度合いがREJECTであるなら、受信された情報は拒絶されます。 さもなければ、取り組んでいる方針に関連している好みの1度はその経路に割り当てられます。 過程が最初のうまくいっているマッチで終わるのに注意してください。 したがって、方針用語は、より特定であるのから、より多くの一般まで注文されるべきです。
The semantics of a matched policy is as follows: If a network in <network-list> that was originally introduced into BGP from <origin> is received via <AS-path>, that network should be redistributed to all ASs in <distribution-list>.
取り組んでいる方針の意味論は以下の通りです: <AS-経路>を通して元々<の起源>からBGPに紹介された<ネットワークリスト>のネットワークを受け取るなら、<発送先リスト>のすべてのASsにそのネットワークを再配付するべきです。
The following examples (some taken from RFC 1102 [3]) illustrate how Policy Terms can be written.
以下の例、(RFC1102[3])から取られた或るものはどうPolicy Termsを書くことができるかを例証します。
In the following topology, H elements are hosts, G elements are Policy Gateways running BGP, and numbered elements are ASs.
以下のトポロジーでは、H要素がホストです、そして、G要素がPolicy Gateways走行BGPです、そして、番号付の要素がASsです。
H1 --- 1 -G12...G21 - 2 -- G23...G32 -- 3 ----- H2
| |
| |
| |
|- G14...G41 - 4 -- G43...G34 ---|- G35...G53 - 5
| |
| |
| H4
H3
H1--- 1-G12…G21--2--G23…G32--3----- H2| | | | | | |- G14…G41--4--G43…G34---|- G35…G53--5| | | | | H4 H3
In this picture, there are four hosts, ten gateways, and five Autonomous Systems. Gateways G12 and G14 belong to AS 1. Gateways G21 and G23 belong to AS 2. Gateways G41 and G43 belongs to AS 4. Gateways G32, G34, and G35 belong to AS 3. Gateway G53 belongs to AS 5. Dashed lines denote intra-AS connections. Dotted lines denote inter-AS connections.
この絵には、4人のホスト、10門、および5Autonomous Systemsがあります。ゲートウェイのG12とG14はAS1に属します。 ゲートウェイのG21とG23はAS2に属します。 ゲートウェイのG41とG43はAS4に属します。 ゲートウェイのG32、G34、およびG35はAS3に属します。 ゲートウェイG53はAS5に属します。 投げつけられた線はイントラ-AS接続を指示します。 点線は相互AS接続を指示します。
First, consider AS 2. It has no hosts attached, and models a transit service, such as the NSFNET backbone network. It may have a very simple policy: it will carry any traffic between any two ASs, without further constraint. If AS 1 and AS 3 are neighboring domains, then its policy term could be written as:
まず最初に、AS2を考えてください。 それは、ホストを全く付けさせないで、NSFNET背骨ネットワークなどのトランジットサービスをモデル化します。 それには、非常に簡単な方針があるかもしれません: それはさらなる規制なしでどんな2ASsの間のどんな交通も運ぶでしょう。 AS1とAS3がドメインを近所付き合いさせているなら、方針用語は以下として書かれるかもしれません。
AS 2: < ANY > < (1 | 3) .* > < IGP > < 1 3 > = 10
2として: <、少しも、><(1|3)*><IGP><1 3>は10と等しいです。
Interconnectivity Working Group [Page 13] RFC 1164 BGP - Application June 1990
相互接続性ワーキンググループ[13ページ]RFC1164BGP--アプリケーション1990年6月
The first component in this policy, the network list
この方針における最初のコンポーネント、ネットワークリスト
< ANY >
<はあらゆる>です。
says that any network is subject to this policy. The second component, the AS path
どんなネットワークもこの方針を受けることがあると言います。 2番目のコンポーネント、AS経路
< (1 | 3) .* >
<(1|3)*>。
says that routing information that came from either AS 1 or AS 3 matches this policy, including routes from ASs that lie beyond AS 1 and AS 3. The third component, the origin
AS1とAS3にあるASsからのルートを含んでいて、AS1かAS3のどちらかから来たルーティング情報がこの方針に合っていると言います。 3番目のコンポーネント、起源
< IGP >
<IGP>。
says that this route must be interior with respect to the originating AS, implying that routes imported via EGP or some other mechanism would not match this policy. The fourth component, the distribution list
EGPを通して輸入されたルートかある他のメカニズムがこの方針に合っていないのを含意して、このルートが由来しているASに関して内部であるに違いないと言います。 4番目のコンポーネント、発送先リスト
< 1 3 >
<1 3>。
says that this route may be redistributed to both AS 1 and AS 3. Finally, the degree of preference assigned to any route which matches this policy is set to 10.
このルートがAS1とAS3の両方に再配付されるかもしれないと言います。 最終的に、この方針に合っているどんなルートにも割り当てられた好みの度合いは10に設定されます。
To improve readability, the above policy can be rewritten as:
読み易さを改良するために、以下として上の方針を書き直すことができます。
AS 2: < ANY > < (1 | 3) ANY* > < IGP > < 1 3 > = 10
2として: <、どんな><、もどんな(1|3)*><IGP><1 3>も=10
Next, consider AS 3. It is willing to provide transit service to AS 4 and AS 5, presumably due to multilateral agreements. AS 3 should set its policy as follows:
次に、AS3を考えてください。 それは、おそらく、多面的な協定のためAS4とAS5に対するトランジットサービスを提供しても構わないと思っています。 AS3は以下の方針を設定するはずです:
AS 3: < ANY > < (4 | 5) > < IGP > < 2 4 5 > = 10
AS 3: < ANY > < 2 .* > < ANY > < 4 5 > = 10
AS 3: < ANY > < 3 > < ANY > < 2 4 5 > = 10
3として: <、3としてのどんな><(4|5)><IGP><2 4 5>も=10: <、どんな><4 5>も10と等しいどんな><2*><、も3: <、どんな><3><、もどんな><2 4 5>も=10
This would allow AS 3 to distribute internal routes received from ASs 4 and 5 to ASs 2, 4, and 5, and all backbone routes through AS 2 would be distributed to ASs 4 and 5. AS 3 would advertise its own networks to ASs 2, 4, and 5. Hosts in AS 4 and AS 5 would be able to reach each other, as well as hosts in ASs 1 and 3 and anything beyond them. AS 3 allows any origin in routes from AS 2. This implies that AS 3 trusts AS 2 to impose policy on routes imported by means other than BGP. Note that although the policy statement would appear to allow AS 3 to send ASs 4 and 5 their own routes, the BGP protocol would detect this as a routing loop and prevent it.
これで、AS3はASs4と5からASs2、4、および5まで受け取られた内部のルートを分配できるでしょう、そして、AS2を通したすべての背骨ルートがASs4と5に分配されるでしょう。 AS3はASs2、4、および5にそれ自身のネットワークの広告を出すでしょう。 AS4とAS5のホストは互いに届くことができるでしょう、ASs1と3のホストと彼らを超えた何でもと同様に。 AS3はAS2からルートによるどんな起源も許容します。 これは、AS3が、AS2がBGP以外の手段で輸入されたルートに方針を課すと信じるのを含意します。 BGPプロトコルが施政方針がAS3がASs4と5にそれら自身のルートを送るのを許容するように見えるでしょうが、ルーティング輪としてこれを検出して、それを防ぐことに注意してください。
Interconnectivity Working Group [Page 14] RFC 1164 BGP - Application June 1990
相互接続性ワーキンググループ[14ページ]RFC1164BGP--アプリケーション1990年6月
Now consider AS 1. AS 1 wishes to use the backbone service provided by AS 2, and is willing to carry transit traffic for AS 4. The policy statements for AS 1 might read:
今度は、AS1を考えてください。 AS1は、AS2によって提供された背骨サービスを利用することを願って、AS4のためにトランジット交通を運んでも構わないと思っています。 AS1のための施政方針は読むかもしれません:
AS 1: < ANY > < 4 > < IGP > < 2 > = 150
AS 1: < ANY > < 2 .* > < ANY > < 4 > = 150
AS 1: < ANY > < 1 > < ANY > < 2 4 > = 150
1として: <、1としてのどんな><4><IGP><2>=150も: <、どんな><4>も150と等しいどんな><2*><、も1: <、どんな>の<の1>の<、もどんな><2 4>も=150
AS 1 will redistribute all routes learned from the AS 2 backbone to AS 4, and vice versa, and distribute routes to its own networks to both AS 2 and AS 4. The degree of preference assigned to any route which matches this policy is set to 150.
AS1はAS2背骨からAS4まで逆もまた同様に学習されたすべてのルートを再配付して、AS2とAS4の両方へのそれ自身のネットワークにルートを分配するでしょう。 この方針に合っているどんなルートにも割り当てられた好みの度合いは150に設定されます。
AS 5 is a more interesting case. AS 5 wishes to use the backbone service, but is not directly connected to AS 2. Its policy statements could be as follows:
AS5は、よりおもしろいケースです。 AS5は背骨サービスを利用することを願っていますが、直接AS2に接続されません。 施政方針は以下の通りであるかもしれません:
AS 5: < ANY > < 3 4 > < IGP > < > = 10
AS 5: < ANY > < 3 2 .* > < . > < > = 10
AS 5: < ANY > < 5 > < . > < 3 > = 10
5として: <、5としてのどんな><3 4><IGP><>も=10: <、5としての><どんな><3 2*><>も=10: <、少しも、><5><><3>は10と等しいです。
This policy imports routes through AS 2 and AS 3 into AS 5, and allows AS 5 and AS 4 to communicate through AS 3. Since AS 5 does not redistribute any routes other than its own, it is a stub AS. Note that AS 5 does not trust AS 3 to advertise only routes through AS 2, and thus applies its own filter to ensure that it only uses the backbone. This lack of trust makes it necessary to add the second policy term.
この方針は、AS5とAS4がAS3を通って交信するのをAS2とAS3を通してAS5にルートを意味して、許容します。 AS5がそれ自身のもの以外のどんなルートも再配付しないので、それはスタッブASです。 AS5がAS3がAS2を通してルートだけの広告を出すと信じないで、その結果、背骨を使用するだけであるのを保証するためにそれ自身のフィルタを申し込むことに注意してください。 信用のこの不足で、2番目の方針用語のときに加えるのは必要になります。
AS 4 is a good example of a multihomed AS. AS 4 wishes to use AS 3 as is primary path to the backbone, with AS 1 as a backup. Furthermore, AS 4 does not wish to provide any transit service between ASs 1 and 3. Its policy statement could read:
AS4はmultihomed ASの好例です。 AS4はAS1と共に第一の経路のようにバックアップとしてAS3を背骨に使用したがっています。 その上、AS4はASs1と3の間にどんなトランジットサービスも供給したがっていません。 施政方針は読むことができました:
AS 4: < ANY > < 3 .* > < ANY > < > = 10
AS 4: < ANY > < 1 .* > < ANY > < > = 20
AS 4: < ANY > < 4 > < ANY > < 1 3 > = 10
4として: <、どんな><>も10と等しいどんな><3*><、も4: <、どんな><>も20と等しいどんな><1*><、も4: <、どんな><4><、もどんな><1 3>も=10
Paths to any network through AS 3 are preferred, but AS 1 will be used as a backup if necessary. Note that since AS 4 trusts AS 3 to provide it with reasonable routes, it is not necessary to explicitly import routes from AS 5. Since the redistribution terms are null except for networks within AS 4, AS 4 will never carry any transit traffic.
AS3を通したどんなネットワークへの経路も好まれますが、必要なら、AS1はバックアップとして使用されるでしょう。 AS4が、AS3が合理的なルートをそれに提供すると信じるのでAS5からルートを明らかに輸入するのは必要でないことに注意してください。 AS4の中のネットワーク以外に、再分配用語がヌルであるので、AS4はどんなトランジット交通も決して運ばないでしょう。
Given the topology and policies described above, it becomes apparent that two paths of equal preference would be available from AS 2 to any of the networks in AS 4. Since ties are not allowed, an
上で説明されたトポロジーと方針を考えて、等しい好みの2つの経路がAS2からAS4のネットワークのどれかまで利用可能であるだろうことは明らかになります。 以来、結びつきは許容されていません。
Interconnectivity Working Group [Page 15] RFC 1164 BGP - Application June 1990
相互接続性ワーキンググループ[15ページ]RFC1164BGP--アプリケーション1990年6月
arbitrary tie-breaking mechanism would come into play (as described above), which might result in less than optimal routes to some networks. An alternative mechanism that would provide optimal routes while still allowing fallback paths would be to provide network-by- network policies in specific cases, and explicit tie-breaking policies for the remaining networks. For example, the policies for AS 2 could be rewritten as follows:
任意の繋がりを壊すメカニズムはプレー(上で説明されるように)に入るでしょう。(それは、いくつかのネットワークへの最適のルート以下をもたらすかもしれません)。 まだ後退経路を許容している間に最適のルートを提供する代替のメカニズムは残っているネットワークのために特定のケース、および明白な繋がりを壊す方針で近くネットワークネットワークに方針を提供するだろうことです。 例えば、以下の通りAS2のための方針を書き直すことができました:
AS 2: < 35 > < 1 .* > < IGP > < 3 > = 10
AS 2: < 35 > < 3 .* > < IGP > < 1 > = 20
AS 2: < ANY > < 1 .* > < IGP > < 3 > = 20
AS 2: < ANY > < 3 .* > < IGP > < 1 > = 10
2として: 2としての<35><1*><IGP><3>=10: 2としての<35><3*><IGP><1>=20: <、2としてのどんな><1*><IGP><3>も=20: <はあらゆる><3*><IGP><1>=10です。
Paths to network 35 through AS 1 would be preferred, with AS 3 as a fallback; paths to all other networks through AS 3 would be preferred over those through AS 1. Such optimizations may become arbitrarily complex.
AS1を通したネットワーク35への経路はAS3と共に後退として好まれるでしょう。 AS3を通した他のすべてのネットワークへの経路はそれらよりAS1を通して好まれるでしょう。 そのような最適化は任意に複雑になるかもしれません。
There may be other, simpler ways to assign a degree of preference to an AS path.
1段階の好みをAS経路に割り当てる他の、そして、より簡単な方法があるかもしれません。
The simplest way to assign a degree of preference to a particular path is to use the number of ASs in the AS path as the degree of preference. This approach reflects the heuristic that shorter paths are usually better than longer ones. This policy can be implemented by using the PathLength() built-in function in the following policy statement:
1段階の好みを特定の経路に割り当てる最も簡単な方法は好みの度合いとしてAS経路のASsの数を使用することです。 このアプローチは、より短い経路があるヒューリスティックを通常より長いものよりよく反映します。 以下の施政方針にPathLength()組込み関数を使用することによって、この政策を実施されることができます:
< ANY > < .* > < ANY > < ANY > = PathLength(ASpath)
<、><*>いずれも<、どんな><、もどんな>もPathLengthと等しいです。(ASpath)
This policy assigns to any network with an arbitrary AS path a degree of preference equal to the number of ASs in the AS path; it then redistributes this information to all other BGP speakers. As an example, an AS path which traverses three different Autonomous Systems will be assigned the degree of preference 3.
この方針は任意のAS経路でAS経路のASsの数と等しい好みの1度をどんなネットワークにも配属します。 そして、それは他のすべてのBGPスピーカーにこの情報を再配付します。 例として、好み3の度合いは3異なったAutonomous Systemsを横断するAS経路に割り当てられるでしょう。
Another approach is to assign a certain degree of preference to each individual AS, and then determine the degree of preference of a particular AS path as the sum of the degree of preferences of the ASs in that path. Note that this approach does not require the assignment of a specific degree of preference to every AS in the Internet. For ASs with an unknown degree of preference, a default can be used. This policy can be implemented by using the PathWeight() built-in function in the following policy statement:
別のアプローチは、その経路のASsの好みの度合いとしてある度の好みをそれぞれの個々のASに割り当てて、次に、特定のAS経路の好みの度合いを決定することです。 このアプローチが特定の度の好みの課題をインターネットのあらゆるASに必要とするというわけではないことに注意してください。 未知の度の好みがあるASsのために、デフォルトを使用できます。 以下の施政方針にPathWeight()組込み関数を使用することによって、この政策を実施されることができます:
< ANY > < .* > < ANY > < ANY >
= PathWeight(ASpath, ASWeightTable)
<、><*>いずれも<、どんな><、もどんな>もPathWeightと等しいです。(ASpath、ASWeightTable)
Interconnectivity Working Group [Page 16] RFC 1164 BGP - Application June 1990
相互接続性ワーキンググループ[16ページ]RFC1164BGP--アプリケーション1990年6月
As an example, if Autonomous Systems 145 and 55 have 10 and 15 as their weights in the ASWeightTable, and if the default degree of preference in the ASWeightTable is 50, then an AS path that traverses Autonomous Systems 145, 164, and 55 will be assigned degree of preference 75.
例として、Autonomous Systems145と55が彼らの体重としてASWeightTableに10と15を持って、ASWeightTableにおける、好みのデフォルト学位が50であるなら、好み75の度合いはAutonomous Systems145、164、および55を横断するAS経路に割り当てられるでしょう。
The above examples demonstrate some of the simple policies that can be implemented with BGP. In general, very sophisticated policies based on partial or complete AS path discrimination can be written and enforced. It should be emphasized that movement toward more sophisticated policies will require parallel effort in creating more sophisticated tools for policy interaction analysis.
上記の例はBGPと共に実施されることができる簡単な政策のいくつかを示します。 一般に、部分的であるか完全なAS経路区別に基づく非常に高度な方針は、書いて、励行できます。 より高度な方針に向かった動きが方針相互作用分析のための、より精巧なツールを作成する際に平行な努力を必要とすると強調されるべきです。
5. The Interaction of BGP and an IGP
5. BGPとIGPの相互作用
5.1 Overview
5.1 概観
By definition, all transit ASs must be able to carry traffic external to that AS (neither the source nor destination host belongs to the AS). This requires a certain degree of interaction and coordination between the Interior Gateway Protocol (IGP) used by that particular AS and BGP. In general, traffic exterior to a given AS is going to pass through both interior gateways (gateways that support IGP only) and border gateways (gateways that support both 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.
定義上、すべてのトランジットASsはそのASへの外部の交通を運ぶことができなければなりません(ソースもあて先ホストもASに属しません)。 これはその特定のASによって使用されたInteriorゲートウェイプロトコル(IGP)とBGPの間のある度の相互作用とコーディネートを必要とします。 一般に、与えられた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 a route to some exterior network X to all of its BGP neighbors in other ASs until all of the interior gateways within the AS are ready to route traffic destined to X 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 other ASs.
そのようなルーティング問題を最小にするために、ASの中の内部のゲートウェイのすべてが正しい出口境界ゲートウェイ(B)を通してXに運命づけられた交通を発送する準備ができるまで、境界ゲートウェイ(A)は他のASsにBGP隣人のすべてへの何らかの外のネットワークXにルートの広告を出すはずがありません。 言い換えれば、他のASsへのその出口ゲートウェイを通してルートの広告を出す前に、内部のルーティングは適切な出口ゲートウェイに集まるべきです。
5.2 Methods for Achieving Stable Interactions
安定した相互作用を達成するための5.2の方法
The following discussion outlines several techniques capable of
以下の議論はできるいくつかのテクニックについて概説します。
Interconnectivity Working Group [Page 17] RFC 1164 BGP - Application June 1990
相互接続性ワーキンググループ[17ページ]RFC1164BGP--アプリケーション1990年6月
achieving stable interactions between BGP and the IGP within an Autonomous System.
Autonomous Systemの中でBGPとIGPとの安定した相互作用を達成します。
5.2.1 Propagation of BGP Information via the IGP
5.2.1 IGPを通したBGP情報の伝播
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情報を運んで、解釈するはずがありませんし、また処理するはずがないことに注意してください。
5.2.2 Tagged Interior Gateway Protocol
5.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 into Internal BGP when propagating this information to other border gateways 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への外のルートに彼らのエキジットポイントのアイデンティティをタグ付けできます。 それぞれの境界ゲートウェイは、同じASの中で他の境界ゲートウェイにこの情報を伝播するとき外のルーティング情報(BGPを通して、受信する)をIGPの中と、そして、Internal BGPの中に発表するのに同じタグを使用するはずです。 境界ゲートウェイで発生するタグは唯一その特定の境界ゲートウェイを特定しなければなりません--異なった境界ゲートウェイは異なったタグを使用しなければなりません。
All Border Gateways within a single AS must observe the following two rules:
独身のASの中のすべてのBorder Gatewaysが以下の2つの規則を守らなければなりません:
1. Information received via Internal BGP by a border gateway A
declaring a network to be unreachable must immediately be
propagated to all of the External BGP neighbors of A.
1. すぐに、ネットワークが手が届かないと宣言しながら境界ゲートウェイAのそばのInternal BGPを通して受け取られた情報をAのExternal BGP隣人のすべてに伝播しなければなりません。
2. Information received via Internal BGP by a border gateway A about
a reachable network X cannot be propagated to any of the External
BGP neighbors of A unless/until A has an IGP route to X and both
the IGP and the BGP routing information have identical tags.
2. Aまでの/がIGPルートをXに持っていない場合、境界ゲートウェイAのそばのInternal BGPを通して届いているネットワークXに関して受け取られた情報はAのExternal BGP隣人のどれかに伝播できません、そして、IGPとBGPルーティング情報の両方には、同じタグがあります。
These rules guarantee that no routing information is announced externally unless the IGP is capable of correctly supporting it. It also avoids some causes of "black holes".
これらの規則は、IGPが正しくそれを支持できないならルーティング情報が全く外部的に発表されないのを保証します。 また、それは「ブラックホール」のいくつかの原因を避けます。
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メッセージの「ゲートウェイ」分野はタグとして使用されます。
Interconnectivity Working Group [Page 18] RFC 1164 BGP - Application June 1990
相互接続性ワーキンググループ[18ページ]RFC1164BGP--アプリケーション1990年6月
5.2.3 Encapsulation
5.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 network X is specified in the "gateway" field of the BGP UPDATE message received from gateway A via Internal BGP by all other border gateways within the same AS. In order to route traffic to network 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のアドレスは同じASの中に他のすべての境界ゲートウェイのそばのInternal BGPを通したゲートウェイAから受け取られたBGP UPDATEメッセージの「ゲートウェイ」分野で指定されます。 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の非常に近くにいるというメモ、そのパケットはカプセル化を実行するゲートウェイで断片化されるでしょう。
5.2.4 Other Cases
5.2.4 他のケース
There may be ASs 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)とASsがあるかもしれません。 さらに、カプセル化は、実行不可能であるか、または望ましくないかもしれません。 そのような状況で、以下の2つの規則を守らなければなりません:
1. Information received via Internal BGP by a border gateway A
declaring a network to be unreachable must immediately be
propagated to all of the External BGP neighbors of A.
1. すぐに、ネットワークが手が届かないと宣言しながら境界ゲートウェイAのそばのInternal BGPを通して受け取られた情報をAのExternal BGP隣人のすべてに伝播しなければなりません。
2. Information received via Internal BGP by a border gateway A about
a reachable network X cannot be propagated to any of the External
BGP neighbors of A unless A has an IGP route to X and sufficient
time (holddown) has passed for the IGP routes to have converged.
2. AがIGPルートをXに持っていない場合、境界ゲートウェイAのそばのInternal BGPを通して届いているネットワークXに関して受け取られた情報はAのExternal BGP隣人のどれかに伝播できません、そして、十分な時間(留め具)は一点に集まったようにIGPルートに適用しました。
The above rules present necessary (but not sufficient) conditions for propagating BGP routing information to other ASs. In contrast to
上の規則はBGPルーティング情報を他のASsに伝播するための必要で(十分でない)の状態を提示します。 in contrast to
Interconnectivity Working Group [Page 19] RFC 1164 BGP - Application June 1990
相互接続性ワーキンググループ[19ページ]RFC1164BGP--アプリケーション1990年6月
tagged IGPs, these rules cannot ensure that interior routes to the proper exit gateways are in place before propagating the routes to other ASs.
タグ付けをされたIGPs、これらの規則は他のASsにルートを伝播する前に、適切な出口ゲートウェイへの内部のルートが適所にあるのを確実にすることができません。
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の集合時間を無視できないなら、異なるアプローチが必要です。 この状況で適切であるかもしれないメカニズムとテクニックはさらなる研究への対象です。
6. Implementation Recommendations
6. 実現推薦
6.1 Multiple Networks Per Message
6.1 複数の1メッセージあたりのネットワーク
The BGP protocol allows for multiple networks with the same AS path and next-hop gateway to be specified in one message. Making use of this capability is highly recommended. With one network per message there is a substantial increase in overhead in the receiver. Not only does the system overhead increase due to the reception of multiple messages, but the overhead of scanning the routing table for flash updates to BGP peers and other routing protocols (and sending the associated messages) is incurred multiple times as well. One method of building messages containing many networks per AS path and gateway from a routing table that is not organized per AS path is to build many messages as the routing table is scanned. As each network is processed, a message for the associated AS path and gateway is allocated, if it does not exist, and the new network is added to it. If such a message exists, the new network is just appended to it. If the message lacks the space to hold the new network, it is transmitted, a new message is allocated, and the new network is inserted into the new message. When the entire routing table has been scanned, all allocated messages are sent and their resources released. Maximum compression is achieved when all networks share a gateway and common path attributes, making it possible to send many networks in one 4096-byte message.
BGPプロトコルは、同じAS経路と次のホップゲートウェイがある複数のネットワークが1つのメッセージで指定されるのを許容します。 この能力を利用するのは非常にお勧めです。 1メッセージあたり1つのネットワークと共に、オーバーヘッドのかなりの増加が受信機にあります。また、システムオーバーヘッドが複数のメッセージのレセプションのため上がるだけではなく、BGP同輩へのフラッシュ最新版と他のルーティング・プロトコル(関連メッセージを送って)のために経路指定テーブルをスキャンするオーバーヘッドは複数の回被られます。 AS経路単位で組織化されない経路指定テーブルから多くのAS経路あたりのネットワークとゲートウェイを含むメッセージを築き上げる1つの方法は経路指定テーブルがスキャンされるとき多くのメッセージを築き上げることです。 各ネットワークを処理するとき、関連AS経路とゲートウェイへのメッセージを割り当てます、存在していなくて、新しいネットワークがそれに加えられるなら。 そのようなメッセージが存在しているなら、ただ新しいネットワークをそれに追加します。 メッセージが新しいネットワークを保持するスペースを欠いているなら、それを伝えます、そして、新しいメッセージを割り当てます、そして、新しいネットワークを新しいメッセージに挿入します。 全体の経路指定テーブルがスキャンされたとき、割り当てられたメッセージを送って、それらのリソースがリリースしたすべてです。 すべてのネットワークがゲートウェイと共通路属性を共有するとき、最大の圧縮は達成されます、1つの4096年のバイトのメッセージで多くのネットワークを送るのを可能にして。
6.2 Preventing Excessive Resource Utilization
6.2 過度のリソース利用を防ぐこと。
When peering with a BGP implementation that does not compress multiple networks into one message, it may be necessary to take steps to reduce the overhead from the flood of data received when a peer is acquired or a significant network topology change occurs. One method of doing this is to rate limit flash updates. This will eliminate
1つのメッセージに複数のネットワークを圧縮しないBGP実現でじっと見るとき、同輩が後天的であるか、または重要なネットワーク形態変化が起こるとき受け取られた膨大なデータからオーバーヘッドを下げるために手を打つのが必要であるかもしれません。 レート限界フラッシュ最新版にはこれをする1つの方法があります。 これは排泄されるでしょう。
Interconnectivity Working Group [Page 20] RFC 1164 BGP - Application June 1990
相互接続性ワーキンググループ[20ページ]RFC1164BGP--アプリケーション1990年6月
the redundant scanning of the routing table to provide flash updates for BGP peers and other routing protocols. A disadvantage of this approach is that it increases the propagation latency of routing information. By choosing a minimum flash update interval that is not much greater than the time it takes to process the multiple messages, this latency should be minimized.
フラッシュを提供する経路指定テーブルの余分なスキャンはBGPのために同輩と他のルーティング・プロトコルをアップデートします。 このアプローチの不都合はルーティング情報の伝播潜在を高めるということです。 わざわざそれが複数のメッセージを処理するあまり長くない最小のフラッシュアップデート間隔を選ぶことによって、この潜在は最小にされるべきです。
6.3 Processing Messages on a Stream Protocol
6.3 流れのプロトコルに関する処理メッセージ
Due to the stream nature of TCP, all the data for received messages does not necessarily arrive at the same time, due to the nature of TCP. This can make it difficult to process the data as messages, especially on systems such as BSD Unix where it is not possible to determine how much data has been received but not yet processed. One method that can be used in this situation is to first try to read just the message header. For the KeepAlive message type, this is a complete message; for other message types, the header should first be verified, in particular the total length. If all checks are successful, the specified length, minus the size of the message header is the amount of data left to read. An implementation that would "hang" the routing information process while trying to read from a peer could set up a message buffer (1024 bytes) per peer and fill it with data as available until a complete message has been received.
TCPの流れの自然のため、受信されたメッセージのためのすべてのデータが同時に必ず到着するというわけではありません、TCPの自然のため。 これで、メッセージとしてデータを処理するのは難しくなる場合があります、どのくらいのデータを受け取りますが、まだ処理していないかを決定するのが可能でないBSD Unixなどのシステムの特に上で。 この状況で使用できる1つの方法は最初にまさしくメッセージヘッダーを読もうとすることです。 KeepAliveメッセージタイプにおいて、これは完全なメッセージです。 他のメッセージタイプにおいて、ヘッダーは最初に、特に確かめられるべきです。全長。 すべてのチェックがうまくいくなら、ヘッダーが読むのを残っているデータ量であるというメッセージのサイズを引いて、指定された長さです。 同輩から読もうとしている間にルーティング情報の過程を「掛かる」実現は、完全なメッセージを受け取るまで同輩単位でメッセージ・バッファ(1024バイト)をセットアップして、利用可能であるとしてデータでそれを満たすかもしれません。
6.4 Processing Update Messages
6.4 処理アップデートメッセージ
In BGP, all Update messages are incremental. Once a particular network is listed in an Update message as being reachable through an AS path and gateway, that piece of information is expected to be retained indefinitely. In order for a route to a network to be removed, it must be explicitly listed in an Update message as being unreachable or with new routing information to replace the old. Note that a BGP peer will only advertise one route to a given network, so any announcement of that network by a particular peer replaces any previous information about that network received from the same peer.
BGPでは、すべてのUpdateメッセージが増加です。 特定のネットワークがAS経路とゲートウェイを通して届くとしてUpdateメッセージにいったん記載されると、その情報が無期限に保有されると予想されます。 ネットワークへのルートが取り外されるためにUpdateメッセージに手が届かないか、新しいルーティング情報で明らかにそれを記載して、老人を取り替えなければなりません。 特定の同輩によるそのネットワークのどんな発表も同じ同輩から受け取られたそのネットワークのどんな前の情報にも取って代わるように、BGP同輩が与えられたネットワークに1つのルートしか広告を出さないことに注意してください。
This approach has the obvious advantage of low overhead; if all routes are stable, only KeepAlive messages will be sent. There is no periodic flood of route information.
このアプローチには、低いオーバーヘッドの明白な利点があります。 すべてのルートが安定していると、KeepAliveメッセージだけを送るでしょう。 経由地案内のどんな周期的な洪水もありません。
However, this means that a consistent view of routing information between BGP peers is only possible over the course of a single transport connection, since there is no mechanism for a complete update. This requirement is accommodated by specifying that BGP peers must transition to the Idle state upon the failure of a transport connection.
しかしながら、これは、BGP同輩の間のルーティング情報の一貫した視点が単独の輸送接続の過程の上で可能であるだけであることを意味します、完全なアップデートのためのメカニズムが全くないので。 BGP同輩は輸送接続の失敗のIdle状態への変遷がそうしなければならないと指定することによって、この要件が設備されます。
Interconnectivity Working Group [Page 21] RFC 1164 BGP - Application June 1990
相互接続性ワーキンググループ[21ページ]RFC1164BGP--アプリケーション1990年6月
7. Conclusion
7. 結論
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. It is hoped that the guidelines presented here will provide a starting point for more sophisticated and manageable routing in the Internet as it grows.
方針と性能規制を実施して、輪を発送するのを避けている間、BGPプロトコルは高い統制度と柔軟性をinterdomainルーティングをするのに提供します。 成長するときここに提示されたガイドラインがインターネットでの、より洗練されて処理しやすいルーティングのための出発点を提供することが望まれています。
References
参照
[1] Lougheed, K. and Y. Rekhter, "A Border Gateway Protocol", RFC
1163, cisco Systems and IBM Watson Research Center, June 1990.
[1] ロッキード、K.、Y.Rekhter、「ボーダ・ゲイトウェイ・プロトコル」、RFC1163、コクチマスSystems、およびIBMワトソン研究所(1990年6月)。
[2] Braun, H-W., "Models of Policy Based Routing", RFC 1104,
Merit/NSFNET, June 1989.
[2] ブラウン、H-W.、「方針のベースのルート設定のモデル」、RFC1104、長所/NSFNET、1989年6月。
[3] Clark, D., "Policy Routing in Internet Protocols", RFC 1102,
M.I.T., May 1989.
[3] クラーク(D.、「インターネットプロトコルにおける方針ルート設定」、RFC1102、マサチューセッツ工科大学)は1989がそうするかもしれません。
Security Considerations
セキュリティ問題
Security issues are not discussed in this memo.
このメモで安全保障問題について議論しません。
Authors' Addresses
作者のアドレス
Jeffrey C. Honig Theory Center 265 Olin Hall Cornell University Ithaca, NY 14853-5201
オリン・ホールコーネル大学イタケー、ジェフリーC.ホニッグ理論センター265ニューヨーク14853-5201
Phone: (607) 255-8686
以下に電話をしてください。 (607) 255-8686
Email: JCH@TCGOULD.TN.CORNELL.EDU
メール: JCH@TCGOULD.TN.CORNELL.EDU
Dave Katz Merit/NSFNET 1075 Beal Ave. Ann Arbor, MI 48109
デーヴキャッツ長所/NSFNET1075ビールAve。 アナーバー、MI 48109
Phone: (313) 763-4898
以下に電話をしてください。 (313) 763-4898
Email: DKATZ@MERIT.EDU
メール: DKATZ@MERIT.EDU
Interconnectivity Working Group [Page 22] RFC 1164 BGP - Application June 1990
相互接続性ワーキンググループ[22ページ]RFC1164BGP--アプリケーション1990年6月
Matt Mathis Pittsburgh Supercomputing Center 4400 Fifth Ave. Pittsburgh, PA 15213
マットマシスピッツバーグSupercomputingは4400黙秘権Aveを中心に置きます。 ピッツバーグ、PA 15213
Phone: (412) 268-3319
以下に電話をしてください。 (412) 268-3319
Email: MATHIS@FARADAY.ECE.CMU.EDU
メール: MATHIS@FARADAY.ECE.CMU.EDU
Yakov Rekhter T.J. Watson Research Center IBM Corporation P.O. Box 218 Yorktown Heights, NY 10598
ニューヨーク ヤコフRekhter T.J.ワトソン研究所IBM社の私書箱218ヨークタウンの高さ、10598
Phone: (914) 945-3896
以下に電話をしてください。 (914) 945-3896
Email: YAKOV@IBM.COM
メール: YAKOV@IBM.COM
Jie Yun (Jessica) Yu Merit/NSFNET 1075 Beal Ave. Ann Arbor, MI 48109
潔ユン(ジェシカ)ユー長所/NSFNET1075ビールAve。 アナーバー、MI 48109
Phone: (313) 936-3000
以下に電話をしてください。 (313) 936-3000
Email: JYY@MERIT.EDU
メール: JYY@MERIT.EDU
Interconnectivity Working Group [Page 23]
相互接続性ワーキンググループ[23ページ]
一覧
スポンサーリンク
