RFC1771 日本語訳
1771 A Border Gateway Protocol 4 (BGP-4). Y. Rekhter, T. Li. March 1995. (Format: TXT=131903 bytes) (Obsoletes RFC1654) (Obsoleted by RFC4271) (Status: DRAFT STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group Y. Rekhter
Request for Comments: 1771 T.J. Watson Research Center, IBM Corp.
Obsoletes: 1654 T. Li
Category: Standards Track cisco Systems
Editors
March 1995
Rekhterがコメントのために要求するワーキンググループY.をネットワークでつないでください: 1771 T.J.ワトソン研究所、IBM社は以下を時代遅れにします。 1654年のT.李カテゴリ: 規格、TrackコクチマスSystemsエディターズ行進1995
A Border Gateway Protocol 4 (BGP-4)
ボーダ・ゲイトウェイ・プロトコル4(BGP-4)
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, "Application of the Border Gateway Protocol in the Internet", define an inter- autonomous system routing protocol for the Internet.
仲間ドキュメントに伴う「インターネットでのボーダ・ゲイトウェイ・プロトコルの応用」というこのドキュメントは相互自律システムルーティング・プロトコルをインターネットと定義します。
1. Acknowledgements
1. 承認
This document was originally published as RFC 1267 in October 1991, jointly authored by Kirk Lougheed (cisco Systems) and Yakov Rekhter (IBM).
このドキュメントはカーク・ロッキード(コクチマスSystems)とヤコフRekhter(IBM)によって共同で書かれた1991年10月に元々、RFC1267として発表されました。
We would like to express our thanks to Guy Almes (ANS), Len Bosack (cisco Systems), and Jeffrey C. Honig (Cornell University) for their contributions to the earlier version of this document.
このドキュメントの以前のバージョンへの彼らの貢献のためにガイAlmes(ANS)、レンBosack(コクチマスSystems)、およびジェフリー・C.ホニッグ(コーネル大学)に感謝したいと思います。
We like to explicitly thank Bob Braden (ISI) for the review of the earlier version of this document as well as his constructive and valuable comments.
私たちは、彼の建設的で貴重なコメントと同様にこのドキュメントの以前のバージョンのレビューについて明らかにボブ・ブレーデン(ISI)に感謝するのが好きです。
We would also like to thank Bob Hinden, Director for Routing of the Internet Engineering Steering Group, and the team of reviewers he assembled to review the previous version (BGP-2) of this document. This team, consisting of Deborah Estrin, Milo Medin, John Moy, Radia Perlman, Martha Steenstrup, Mike St. Johns, and Paul Tsuchiya, acted with a strong combination of toughness, professionalism, and courtesy.
また、彼がこのドキュメントの旧バージョン(BGP-2)を見直すために集合したのをボブHinden、インターネットEngineering Steering Groupのルート設定、および評論家のチームのディレクターに感謝申し上げます。 このチーム(デボラEstrin、ミロ・メディン、ジョンMoy、Radiaパールマン、マーサ・ステーンストルプ、マイク通りジョーンズから成って、ポールTsuchiya)は、強度、プロフェッショナリズム、および礼儀の強い組み合わせで行動しました。
Rekhter & Li [Page 1] RFC 1771 BGP-4 March 1995
Rekhterと李[1ページ]RFC1771BGP-1995年3月4日
This updated version of the document is the product of the IETF IDR Working Group with Yakov Rekhter and Tony Li as editors. Certain sections of the document borrowed heavily from IDRP [7], which is the OSI counterpart of BGP. For this credit should be given to the ANSI X3S3.3 group chaired by Lyman Chapin (BBN) and to Charles Kunzinger (IBM Corp.) who was the IDRP editor within that group. We would also like to thank Mike Craren (Proteon, Inc.), Dimitry Haskin (Bay Networks, Inc.), John Krawczyk (Bay Networks, Inc.), and Paul Traina (cisco Systems) for their insightful comments.
ドキュメントのこのアップデートされたバージョンはヤコフRekhterがあるIETF IDR作業部会とエディタとしてのトニー・李の製品です。 ドキュメントのある一定のセクションはIDRP[7]から大いに借りました。(IDRPはBGPのOSI対応者です)。 ライマン・チェーピンによってまとめられたANSI X3S3.3グループ(BBN)と、そして、そのグループの中のIDRPエディタであったチャールズKunzinger(IBM社)にこのクレジットを与えるべきであるので。 また、彼らの洞察に満ちたコメントについてマイクCraren(Proteon Inc.)、ドミトリー・ハスキン(ベイネットワークスInc.)、ジョンKrawczyk(ベイネットワークスInc.)、およびポールTraina(コクチマスSystems)に感謝申し上げます。
We would like to specially acknowledge numerous contributions by Dennis Ferguson (MCI).
特に、デニスファーガソン(MCI)による頻繁な貢献を承諾したいと思います。
The work of Yakov Rekhter was supported in part by the National Science Foundation under Grant Number NCR-9219216.
ヤコフRekhterの仕事はグラントNumber NCR-9219216の下で国立科学財団によって一部支持されました。
2. Introduction
2. 序論
The Border Gateway Protocol (BGP) is an inter-Autonomous System routing protocol. It is built on experience gained with EGP as defined in RFC 904 [1] and EGP usage in the NSFNET Backbone as described in RFC 1092 [2] and RFC 1093 [3].
ボーダ・ゲイトウェイ・プロトコル(BGP)は相互Autonomous Systemルーティング・プロトコルです。 それはEGPと共にNSFNET BackboneのRFC904[1]とEGP用法で定義されるように行われた経験のときにRFC1092[2]とRFC1093[3]で説明されるように建てられます。
The primary function of a BGP speaking system is to exchange network reachability information with other BGP systems. This network reachability information includes information on the list of Autonomous Systems (ASs) that reachability information traverses. This information is sufficient to construct a graph of AS connectivity from which routing loops may be pruned and some policy decisions at the AS level may be enforced.
BGPがシステムを話す第一の機能は他のBGPシステムとネットワーク可到達性情報を交換することです。このネットワーク可到達性情報は可到達性情報が横断するAutonomous Systems(ASs)のリストの上の情報を含んでいます。 この情報は、ルーティング輪余計なものを取り除かれるかもしれなくて、ASレベルにおけるいくつかの政策決定が励行されるかもしれないASの接続性のグラフを作図するために十分です。
BGP-4 provides a new set of mechanisms for supporting classless interdomain routing. These mechanisms include support for advertising an IP prefix and eliminates the concept of network "class" within BGP. BGP-4 also introduces mechanisms which allow aggregation of routes, including aggregation of AS paths. These changes provide support for the proposed supernetting scheme [8, 9].
BGP-4は階級のないinterdomainルーティングを支持するのに新しいセットのメカニズムを提供します。 これらのメカニズムは、IP接頭語の広告を出すサポートを含んで、BGPの中でネットワーク「クラス」の概念を排除します。 また、BGP-4はAS経路の集合を含むルートの集合を許容するメカニズムを紹介します。 これらの変化は提案されたスーパーネッティング計画[8、9]のサポートを提供します。
To characterize the set of policy decisions that can be enforced using BGP, one must focus on the rule that a BGP speaker advertise to its peers (other BGP speakers which it communicates with) in neighboring ASs only those routes that it itself uses. This rule reflects the "hop-by-hop" routing paradigm generally used throughout the current Internet. Note that some policies cannot be supported by the "hop-by-hop" routing paradigm and thus require techniques such as source routing to enforce. For example, BGP does not enable one AS to send traffic to a neighboring AS intending that the traffic take a different route from that taken by traffic originating in the
BGP、1を使用することで励行されることができる政策決定のセットを特徴付けるのはBGPスピーカーが隣接しているASsのそれ自体が使用するそれらの(それがコミュニケートする他のBGPスピーカー)ルートだけの同輩に広告を出すという規則に焦点を合わせなければなりません。 この規則は一般に、現在のインターネット中で使用される「ホップごとの」ルーティングパラダイムを反映します。 いくつかの方針が「ホップごとの」ルーティングパラダイムによってサポートされて、その結果、実施するソースルーティングなどのテクニックを必要とすることができないことに注意してください。 例えば、BGPは、1ASが交通が起こる交通で取られたそれと異なったルートを取ることを意図する隣接しているASに交通を送るのを可能にしません。
Rekhter & Li [Page 2] RFC 1771 BGP-4 March 1995
Rekhterと李[2ページ]RFC1771BGP-1995年3月4日
neighboring 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.
ASを近所付き合いさせます。 他方では、BGPは「ホップごとの」ルーティングパラダイムに従うどんな方針も支持できます。 現在のインターネットが「ホップごとの」ルーティングパラダイムだけを使用して、BGPがそのパラダイムに従うどんな方針も支持できるので、BGPは現在のインターネットへの相互ASルーティング・プロトコルとして非常に適切です。
A more complete discussion of what policies can and cannot be enforced with BGP is outside the scope of this document (but refer to the companion document discussing BGP usage [5]).
しかし、このドキュメントの範囲の外にどんな方針を励行できて、BGPと共に励行できないかに関する、より完全な議論がある、(BGP用法[5])について議論しながら、仲間ドキュメントを参照してください。
BGP runs over a reliable transport protocol. This eliminates the need to implement explicit update fragmentation, retransmission, acknowledgement, and sequencing. Any authentication scheme used by the transport protocol may be used in addition to BGP's own authentication mechanisms. The error notification mechanism used in BGP assumes that the transport protocol supports a "graceful" close, i.e., that all outstanding data will be delivered before the connection is closed.
BGPは信頼できるトランスポート・プロトコルをひきます。 これは明白なアップデート断片化、「再-トランスミッション」、承認、および配列を実行する必要性を排除します。 トランスポート・プロトコルによって使用されるどんな認証計画もBGPの自身の認証機構に加えて使用されるかもしれません。BGPで使用されるエラー通知メカニズムは、トランスポート・プロトコルが「優雅な」閉鎖を支持して、すなわち、接続が閉じるようになる前にすべての傑出しているデータが送られると仮定します。
BGP uses TCP [4] as its transport protocol. TCP meets BGP's transport requirements and is present in virtually all commercial routers and hosts. In the following descriptions the phrase "transport protocol connection" can be understood to refer to a TCP connection. BGP uses TCP port 179 for establishing its connections.
BGPはトランスポート・プロトコルとしてTCP[4]を使用します。 TCPはBGPの輸送必要条件を満たして、ほとんどすべての商業ルータとホストに存在しています。 以下の記述では、TCP接続について言及するのを「輸送プロトコル接続」という句を理解できます。 BGPは、接続を確立するのにTCPポート179を使用します。
This document uses the term `Autonomous System' (AS) 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 destinations are reachable through it.
このドキュメントはあらゆる点で'自治のSystem'(AS)という用語を使用します。 Autonomous Systemの古典的な定義はただ一つの技術的な管理の下で、1セットのルータです、ASの中でパケットを発送するのに内部のゲートウェイプロトコルと一般的な測定基準を使用して、他のASsにパケットを発送するのに外のゲートウェイプロトコルを使用して。 この古典的な定義が開発されて以来、独身のASがASの中でいくつかの内部のゲートウェイプロトコルと時々数セットの測定基準を使用するのは一般的になっています。 ここでのAutonomous Systemという用語の使用は、ただ一つの論理的な内部のルーティングプランを持つために、複数のIGPsと測定基準が使用されてさえいるとき、ASの管理が他のASsにおいて現れるという事実を強調して、どんな目的地がそれを通して届いているかに関する一貫した絵を提示します。
The planned use of BGP in the Internet environment, including such issues as topology, the interaction between BGP and IGPs, and the enforcement of routing policy rules is presented in a companion document [5]. This document is the first of a series of documents planned to explore various aspects of BGP application. Please send comments to the BGP mailing list (bgp@ans.net).
トポロジーのような問題、BGPとIGPsとの相互作用を含むインターネット環境におけるBGPの計画された使用とルーティング政策ルールの実施は仲間ドキュメント[5]に示されます。 このドキュメントはドキュメントのシリーズものの第1作が、BGPアプリケーションの種々相を探検するのを計画していたということです。 BGPメーリングリスト( bgp@ans.net )にコメントを送ってください。
Rekhter & Li [Page 3] RFC 1771 BGP-4 March 1995
Rekhterと李[3ページ]RFC1771BGP-1995年3月4日
3. Summary of Operation
3. 操作の概要
Two systems form a transport protocol connection between one another. They exchange messages to open and confirm the connection parameters. The initial data flow is the entire BGP routing table. Incremental updates are sent as the routing tables change. BGP does not require periodic refresh of the entire BGP routing table. Therefore, a BGP speaker must retain the current version of the entire BGP routing tables of all of its peers for the duration of the connection. KeepAlive messages are sent periodically to ensure the liveness of the connection. Notification messages are sent in response to errors or special conditions. If a connection encounters an error condition, a notification message is sent and the connection is closed.
2台のシステムがお互いの間の輸送プロトコル接続を形成します。 彼らは接続パラメタを開いて、確認するメッセージを交換します。 初期のデータフローは全体のBGP経路指定テーブルです。 経路指定テーブルが変化するとき、アップデート増加を送ります。 BGPは必要でない、周期的である、全体のBGP経路指定テーブルをリフレッシュしてください。 したがって、BGPスピーカーは接続の持続時間のための同輩のすべての全体のBGP経路指定テーブルの最新版を保有しなければなりません。 接続の活性を確実にするために定期的にKeepAliveメッセージを送ります。 誤りか特別な状態に対応して通知メッセージを送ります。 接続がエラー条件に遭遇するなら、通知メッセージを送ります、そして、接続は閉じます。
The hosts executing the Border Gateway Protocol need not be routers. A non-routing host could exchange routing information with routers via EGP or even an interior routing protocol. That non-routing host could then use BGP to exchange routing information with a border router in another Autonomous System. The implications and applications of this architecture are for further study.
ボーダ・ゲイトウェイ・プロトコルを実行するホストはルータである必要はありません。 非ルーティングホストはEGPか内部のルーティング・プロトコルでさえルーティング情報をルータと交換できるでしょう。 そして、その非ルーティングホストは、別のAutonomous Systemの境界ルータとルーティング情報を交換するのにBGPを使用できました。 さらなる研究にはこの構造の含意と利用があります。
If a particular AS has multiple BGP speakers and is providing transit service for other ASs, then care must be taken to ensure a consistent view of routing within the AS. A consistent view of the interior routes of the AS is provided by the interior routing protocol. A consistent view of the routes exterior to the AS can be provided by having all BGP speakers within the AS maintain direct BGP connections with each other. Using a common set of policies, the BGP speakers arrive at an agreement as to which border routers will serve as exit/entry points for particular destinations outside the AS. This information is communicated to the AS's internal routers, possibly via the interior routing protocol. Care must be taken to ensure that the interior routers have all been updated with transit information before the BGP speakers announce to other ASs that transit service is being provided.
特定のASが複数のBGPスピーカーがいて、トランジットサービスを他のASsに供給しているなら、ASの中でルーティングの一貫した視点を確実にするために注意しなければなりません。 内部のルーティング・プロトコルはASの内部のルートの一貫した意見を提供します。 ASの中のすべてのBGPスピーカーに互いとのダイレクトBGP接続を維持させることによって、ASへの外のルートの一貫した意見を提供できます。 一般的なセットの方針を使用して、出口/エントリーがASの外の特定の目的地に指すときどの境界ルータが役立つかに関してBGPスピーカーは合意に達します。 この情報はことによると内部のルーティング・プロトコルでASの内部のルータに伝えられます。 BGPスピーカーがトランジットサービスが提供されている他のASsに知らせる前にトランジット情報で内部のルータをすべてアップデートしたのを保証するために注意しなければなりません。
Connections between BGP speakers of different ASs are referred to as "external" links. BGP connections between BGP speakers within the same AS are referred to as "internal" links. Similarly, a peer in a different AS is referred to as an external peer, while a peer in the same AS may be described as an internal peer.
異なったASsのBGPスピーカーの間のコネクションズは「外部」のリンクと呼ばれます。 同じASの中のBGPスピーカーの間のBGP接続は「内部」のリンクと呼ばれます。 同様に、異なったASの同輩は外部の同輩と呼ばれます、同じASの同輩が内部の同輩として記述されているかもしれませんが。
Rekhter & Li [Page 4] RFC 1771 BGP-4 March 1995
Rekhterと李[4ページ]RFC1771BGP-1995年3月4日
3.1 Routes: Advertisement and Storage
3.1のルート: 広告と格納
For purposes of this protocol a route is defined as a unit of information that pairs a destination with the attributes of a path to that destination:
このプロトコルの目的のために、ルートはその目的地への経路の属性と目的地を対にする情報のユニットと定義されます:
- Routes are advertised between a pair of BGP speakers in UPDATE
messages: the destination is the systems whose IP addresses are
reported in the Network Layer Reachability Information (NLRI)
field, and the the path is the information reported in the path
attributes fields of the same UPDATE message.
- UPDATEメッセージの1組のBGPスピーカーの間にルートの広告を出します: 目的地はIPアドレスがNetwork Layer Reachability情報(NLRI)分野で報告されるシステムです、そして、経路は同じUPDATEメッセージの経路属性分野で報告された情報です。
- Routes are stored in the Routing Information Bases (RIBs):
namely, the Adj-RIBs-In, the Loc-RIB, and the Adj-RIBs-Out. Routes
that will be advertised to other BGP speakers must be present in
the Adj-RIB-Out; routes that will be used by the local BGP speaker
must be present in the Loc-RIB, and the next hop for each of these
routes must be present in the local BGP speaker's forwarding
information base; and routes that are received from other BGP
speakers are present in the Adj-RIBs-In.
- ルートは経路情報基地(RIBs)の中に格納されます: すなわち、中のAdj-RIBs、Loc-RIB、および外のAdj-RIBs。 他のBGPスピーカーに広告に掲載されているルートは外のAdj-RIBに存在していなければなりません。 使用されるルートはLoc-RIBに地元のBGPスピーカーで存在していなければなりません、そして、それぞれのこれらのルートへの次のホップは地元のBGPスピーカーの推進情報ベースの中に存在していなければなりません。 そして、他のBGPスピーカーから受け取られていているルートは中のAdj-RIBsに存在しています。
If a BGP speaker chooses to advertise the route, it may add to or modify the path attributes of the route before advertising it to a peer.
BGPスピーカーが、ルートの広告を出すのを選ぶなら、同輩にそれの広告を出す前に、それは、ルートについて加えるか、または経路属性を変更するかもしれません。
BGP provides mechanisms by which a BGP speaker can inform its peer that a previously advertised route is no longer available for use. There are three methods by which a given BGP speaker can indicate that a route has been withdrawn from service:
BGPはBGPスピーカーが以前に広告を出したルートがもう使用に利用可能でないことを同輩に知らせることができるメカニズムを提供します。 与えられたBGPスピーカーが、ルートがサービスから引っ込められたのを示すことができる3つの方法があります:
a) the IP prefix that expresses destinations for a previously
advertised route can be advertised in the WITHDRAWN ROUTES field
in the UPDATE message, thus marking the associated route as being
no longer available for use
a) UPDATEメッセージのWITHDRAWN ROUTES分野に以前に広告を出したルートに目的地を言い表すIP接頭語は広告を出すことができます、その結果、もう使用に利用可能でないとして関連ルートをマークします。
b) a replacement route with the same Network Layer Reachability
Information can be advertised, or
またはb) 同じNetwork Layer Reachability情報がある交換ルートの広告を出すことができる。
c) the BGP speaker - BGP speaker connection can be closed, which
implicitly removes from service all routes which the pair of
speakers had advertised to each other.
c) BGPスピーカー--BGPスピーカー接続(それとなくサービスからスピーカーの組が互いに広告を出したすべてのルートを取り外す)は閉店できます。
Rekhter & Li [Page 5] RFC 1771 BGP-4 March 1995
Rekhterと李[5ページ]RFC1771BGP-1995年3月4日
3.2 Routing Information Bases
3.2 経路情報基地
The Routing Information Base (RIB) within a BGP speaker consists of three distinct parts:
BGPスピーカーの中の経路情報基地(RIB)は3つの異なった部品から成ります:
a) Adj-RIBs-In: The Adj-RIBs-In store routing information that has
been learned from inbound UPDATE messages. Their contents
represent routes that are available as an input to the Decision
Process.
a) 中のAdjあばら骨: 本国行きのUPDATEメッセージから学習された用意してAdj-RIBsルーティング情報。 それらの内容は入力としてDecision Processに利用可能なルートを表します。
b) Loc-RIB: The Loc-RIB contains the local routing information
that the BGP speaker has selected by applying its local policies
to the routing information contained in its Adj-RIBs-In.
b) Loc-あばら骨: Loc-RIBはBGPスピーカーが中のAdj-RIBsに含まれたルーティング情報にローカルの方針を適用することによって選択したローカルのルーティング情報を含んでいます。
c) Adj-RIBs-Out: The Adj-RIBs-Out store the information that the
local BGP speaker has selected for advertisement to its peers. The
routing information stored in the Adj-RIBs-Out will be carried in
the local BGP speaker's UPDATE messages and advertised to its
peers.
c) Adjあばら骨アウト: 外のAdj-RIBsは地元のBGPスピーカーが広告のために同輩に選択した情報を格納します。 外のAdj-RIBsに格納されたルーティング情報の、地元のBGPスピーカーのUPDATEメッセージで運んで、同輩に広告を出すでしょう。
In summary, the Adj-RIBs-In contain unprocessed routing information that has been advertised to the local BGP speaker by its peers; the Loc-RIB contains the routes that have been selected by the local BGP speaker's Decision Process; and the Adj-RIBs-Out organize the routes for advertisement to specific peers by means of the local speaker's UPDATE messages.
概要では、中のAdj-RIBsは同輩によって地元のBGPスピーカーに広告に掲載されている未加工のルーティング情報を含んでいます。 Loc-RIBは地元のBGPスピーカーのDecision Processによって選択されたルートを含んでいます。 そして、外のAdj-RIBsは地元のスピーカーのUPDATEメッセージによって特定の同輩に広告のためのルートを組織化します。
Although the conceptual model distinguishes between Adj-RIBs-In, Loc-RIB, and Adj-RIBs-Out, this neither implies nor requires that an implementation must maintain three separate copies of the routing information. The choice of implementation (for example, 3 copies of the information vs 1 copy with pointers) is not constrained by the protocol.
概念モデルは中のAdj-RIBs、Loc-RIB、および外のAdj-RIBsを見分けますが、これは、実現がルーティング情報の別々のコピー3部を維持しなければならないのを含意でない、また必要としません。 実現(例えば、情報対1のコピー3部はポインタでコピーされる)の選択はプロトコルによって抑制されません。
4. Message Formats
4. メッセージ・フォーマット
This section describes message formats used by BGP.
このセクションはBGPによって使用されたメッセージ・フォーマットについて説明します。
Messages are sent over a reliable transport protocol connection. A message is processed only after it is entirely received. The maximum message size is 4096 octets. All implementations are required to support this maximum message size. The smallest message that may be sent consists of a BGP header without a data portion, or 19 octets.
頼もしい輸送プロトコル接続の上にメッセージを送ります。 それを完全に受け取った後にだけメッセージを処理します。 最大のメッセージサイズは4096の八重奏です。 すべての実現が、この最大のメッセージサイズを支持するのに必要です。 送られるかもしれない中で最も小さいメッセージはデータ部も、または19の八重奏なしでBGPヘッダーから成ります。
Rekhter & Li [Page 6] RFC 1771 BGP-4 March 1995
Rekhterと李[6ページ]RFC1771BGP-1995年3月4日
4.1 Message Header Format
4.1 メッセージヘッダー形式
Each message has a fixed-size header. There may or may not be a data portion following the header, depending on the message type. The layout of these fields is shown below:
各メッセージには、固定サイズヘッダーがあります。 メッセージタイプに頼っていて、ヘッダーに続くデータ部があるかもしれません。 これらの分野のレイアウトは以下に示されます:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ +
| Marker |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + + | マーカー| + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 長さ| タイプ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Marker:
マーカー:
This 16-octet field contains a value that the receiver of the
message can predict. If the Type of the message is OPEN, or if
the OPEN message carries no Authentication Information (as an
Optional Parameter), then the Marker must be all ones.
Otherwise, the value of the marker can be predicted by some a
computation specified as part of the authentication mechanism
(which is specified as part of the Authentication Information)
used. The Marker can be used to detect loss of synchronization
between a pair of BGP peers, and to authenticate incoming BGP
messages.
この16八重奏の分野はメッセージの受信機が予測できる値を含んでいます。 メッセージのTypeがオープンである、またはオープンメッセージがAuthentication情報(Optional Parameterとしての)を全く運ばないなら、Markerはすべてものであるに違いありません。 さもなければ、計算が使用される認証機構(Authentication情報の一部として指定される)の一部として指定した何かはマーカーの値を予測できます。 1組のBGP同輩の間の同期の損失を検出して、入って来るBGPメッセージを認証するのにMarkerを使用できます。
Length:
長さ:
This 2-octet unsigned integer indicates the total length of the
message, including the header, in octets. Thus, e.g., it
allows one to locate in the transport-level stream the (Marker
field of the) next message. The value of the Length field must
always be at least 19 and no greater than 4096, and may be
further constrained, depending on the message type. No
"padding" of extra data after the message is allowed, so the
Length field must have the smallest value required given the
rest of the message.
この2八重奏の符号のない整数は八重奏にヘッダーを含むメッセージの全長を示します。 1つがこのようにして、そして、例えば、それで輸送レベルストリームで場所を見つけることができる、(マーカー分野、)、次のメッセージ。 Length分野の値は、いつも少なくとも19と、4096以下と、さらに抑制されるかもしれなくて、メッセージタイプに頼ることでなければなりません。 メッセージが許容された後に付加的なデータのどんな「詰め物」によっても、メッセージの残りを考えて、Length分野で最も小さい値を必要としてはいけません。
Rekhter & Li [Page 7] RFC 1771 BGP-4 March 1995
Rekhterと李[7ページ]RFC1771BGP-1995年3月4日
Type:
以下をタイプしてください。
This 1-octet unsigned integer indicates the type code of the
message. The following type codes are defined:
この1八重奏の符号のない整数はメッセージのタイプコードを示します。 以下のタイプコードは定義されます:
1 - OPEN
2 - UPDATE
3 - NOTIFICATION
4 - KEEPALIVE
1--開いている2--アップデート3--通知4--KEEPALIVE
4.2 OPEN Message Format
4.2 開いているメッセージ・フォーマット
After a transport protocol connection is established, the first message sent by each side is an OPEN message. If the OPEN message is acceptable, a KEEPALIVE message confirming the OPEN is sent back. Once the OPEN is confirmed, UPDATE, KEEPALIVE, and NOTIFICATION messages may be exchanged.
輸送プロトコル接続が確立された後に、それぞれの側によって送られた最初のメッセージはオープンメッセージです。 オープンメッセージが許容できるなら、オープンを確認するKEEPALIVEメッセージは返送されます。 いったんオープンを確認すると、UPDATE、KEEPALIVE、およびNOTIFICATIONメッセージを交換するかもしれません。
In addition to the fixed-size BGP header, the OPEN message contains the following fields:
固定サイズBGPヘッダーに加えて、オープンメッセージは以下の分野を含んでいます:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+
| Version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| My Autonomous System |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hold Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BGP Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opt Parm Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Optional Parameters |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+ | バージョン| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 私の自律システム| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 保持時間| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BGP識別子| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Parmレンを選んでください。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | 任意のパラメタ| | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version:
バージョン:
This 1-octet unsigned integer indicates the protocol version
number of the message. The current BGP version number is 4.
この1八重奏の符号のない整数はメッセージのプロトコルバージョン番号を示します。 現在のBGPバージョン番号は4です。
My Autonomous System:
私の自律システム:
This 2-octet unsigned integer indicates the Autonomous System
number of the sender.
この2八重奏の符号のない整数は送付者のAutonomous System番号を示します。
Rekhter & Li [Page 8] RFC 1771 BGP-4 March 1995
Rekhterと李[8ページ]RFC1771BGP-1995年3月4日
Hold Time:
保持時間:
This 2-octet unsigned integer indicates the number of seconds
that the sender proposes for the value of the Hold Timer. Upon
receipt of an OPEN message, a BGP speaker MUST calculate the
value of the Hold Timer by using the smaller of its configured
Hold Time and the Hold Time received in the OPEN message. The
Hold Time MUST be either zero or at least three seconds. An
implementation may reject connections on the basis of the Hold
Time. The calculated value indicates the maximum number of
seconds that may elapse between the receipt of successive
KEEPALIVE, and/or UPDATE messages by the sender.
この2八重奏の符号のない整数は送付者がHold Timerの値のために提案する秒数を示します。 オープンメッセージを受け取り次第、BGPスピーカーは、オープンメッセージに受け取られた構成されたHold TimeとHold Timeについて、より小さいのを使用することによって、Hold Timerの値について計算しなければなりません。 Hold Timeはゼロか少なくとも3秒のどちらかでなければなりません。 実装はHold Timeに基づいて接続を拒絶するかもしれません。 計算された値は連続したKEEPALIVEの領収書、そして/または、送付者によるUPDATEメッセージの間で経過するかもしれない秒の最大数を示します。
BGP Identifier:
BGP識別子:
This 4-octet unsigned integer indicates the BGP Identifier of
the sender. A given BGP speaker sets the value of its BGP
Identifier to an IP address assigned to that BGP speaker. The
value of the BGP Identifier is determined on startup and is the
same for every local interface and every BGP peer.
この4八重奏の符号のない整数は送付者のBGP Identifierを示します。 与えられたBGPスピーカーはそのBGPスピーカーに割り当てられたIPアドレスにBGP Identifierの値を設定します。 BGP Identifierの値は、始動で決定していて、あらゆる局所界面とすべてのBGP同輩にとって、同じです。
Optional Parameters Length:
任意のパラメタの長さ:
This 1-octet unsigned integer indicates the total length of the
Optional Parameters field in octets. If the value of this field
is zero, no Optional Parameters are present.
この1八重奏の符号のない整数は八重奏における、Optional Parameters分野の全長を示します。 この分野の値がゼロであるなら、どんなOptional Parametersも存在していません。
Optional Parameters:
任意のパラメタ:
This field may contain a list of optional parameters, where
each parameter is encoded as a <Parameter Type, Parameter
Length, Parameter Value> triplet.
この分野は任意のパラメタのリストを含むかもしれません、Parameter Length、Parameter Value>三つ子。そこでは、各パラメタが<Parameter Typeとしてコード化されます。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
| Parm. Type | Parm. Length | Parameter Value (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... | Parm。 タイプ| Parm。 長さ| パラメタ価値(可変)の++++++++++++++++++++、-、…
Parameter Type is a one octet field that unambiguously
identifies individual parameters. Parameter Length is a one
octet field that contains the length of the Parameter Value
field in octets. Parameter Value is a variable length field
that is interpreted according to the value of the Parameter
Type field.
パラメタTypeは明白に個々のパラメタを特定する1つの八重奏分野です。 パラメタLengthは八重奏における、Parameter Value分野の長さを含む1つの八重奏分野です。 パラメタValueはParameter Type分野の値に従って解釈される可変長フィールドです。
Rekhter & Li [Page 9] RFC 1771 BGP-4 March 1995
Rekhterと李[9ページ]RFC1771BGP-1995年3月4日
This document defines the following Optional Parameters:
このドキュメントは以下のOptional Parametersを定義します:
a) Authentication Information (Parameter Type 1):
a) 認証情報(パラメータの型1):
This optional parameter may be used to authenticate a BGP
peer. The Parameter Value field contains a 1-octet
Authentication Code followed by a variable length
Authentication Data.
この任意のパラメタは、BGP同輩を認証するのに使用されるかもしれません。 Parameter Value分野は可変長に従ってAuthentication Codeが続いた1八重奏Authentication Dataを含んでいます。
0 1 2 3 4 5 6 7 8
+-+-+-+-+-+-+-+-+
| Auth. Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Authentication Data |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 4 5 6 7 8 +-+-+-+-+-+-+-+-+ | Auth。 コード| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | 認証データ| | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Authentication Code:
認証コード:
This 1-octet unsigned integer indicates the
authentication mechanism being used. Whenever an
authentication mechanism is specified for use within
BGP, three things must be included in the
specification:
この1八重奏の符号のない整数は使用される認証機構を示します。 認証機構がBGPの中の使用に指定されるときはいつも、仕様に3つのものを含まなければなりません:
- the value of the Authentication Code which indicates
use of the mechanism,
- the form and meaning of the Authentication Data, and
- the algorithm for computing values of Marker fields.
- そして、メカニズムの使用を示すAuthentication Codeの値--Authentication Dataのフォームと意味、--Marker分野の値を計算するためのアルゴリズム。
Note that a separate authentication mechanism may be
used in establishing the transport level connection.
別々の認証機構が輸送レベル接続を確立する際に使用されるかもしれないことに注意してください。
Authentication Data:
認証データ:
The form and meaning of this field is a variable-
length field depend on the Authentication Code.
この分野のフォームと意味は可変長さの分野をAuthentication Codeに依存するということです。
The minimum length of the OPEN message is 29 octets (including
message header).
オープンメッセージの最小の長さは29の八重奏(メッセージヘッダーを含んでいて)です。
Rekhter & Li [Page 10] RFC 1771 BGP-4 March 1995
Rekhterと李[10ページ]RFC1771BGP-1995年3月4日
4.3 UPDATE Message Format
4.3 アップデートメッセージ・フォーマット
UPDATE messages are used to transfer routing information between BGP peers. The information in the UPDATE packet can be used to construct a graph describing the relationships of the various Autonomous Systems. By applying rules to be discussed, routing information loops and some other anomalies may be detected and removed from inter-AS routing.
UPDATEメッセージは、BGP同輩の間にルーティング情報を移すのに使用されます。 様々なAutonomous Systemsの関係について説明するグラフを作図するのにUPDATEパケットの情報を使用できます。議論するために規則を適用することによって、ルーティング情報輪とある他の例外は、相互ASルーティングから検出されて、取り外されるかもしれません。
An UPDATE message is used to advertise a single feasible route to a peer, or to withdraw multiple unfeasible routes from service (see 3.1). An UPDATE message may simultaneously advertise a feasible route and withdraw multiple unfeasible routes from service. The UPDATE message always includes the fixed-size BGP header, and can optionally include the other fields as shown below:
UPDATEメッセージは、ただ一つの可能なルートの同輩に広告を出すか、またはサービスから複数の実行不可能なルートを引っ込めるのに使用されます(3.1を見てください)。 UPDATEメッセージは、同時に、可能なルートの広告を出して、サービスから複数の実行不可能なルートを引っ込めるかもしれません。 UPDATEメッセージは、いつも固定サイズBGPヘッダーを含んでいて、任意に以下に示すように他の分野を含むことができます:
+-----------------------------------------------------+
| Unfeasible Routes Length (2 octets) |
+-----------------------------------------------------+
| Withdrawn Routes (variable) |
+-----------------------------------------------------+
| Total Path Attribute Length (2 octets) |
+-----------------------------------------------------+
| Path Attributes (variable) |
+-----------------------------------------------------+
| Network Layer Reachability Information (variable) |
+-----------------------------------------------------+
+-----------------------------------------------------+ | 実行不可能なRoutes Length(2つの八重奏)| +-----------------------------------------------------+ | よそよそしいルート(可変)| +-----------------------------------------------------+ | 総Path Attribute Length(2つの八重奏)| +-----------------------------------------------------+ | 経路属性(可変)| +-----------------------------------------------------+ | ネットワーク層可到達性情報(可変)| +-----------------------------------------------------+
Unfeasible Routes Length:
実行不可能なルートの長さ:
This 2-octets unsigned integer indicates the total length of
the Withdrawn Routes field in octets. Its value must allow the
length of the Network Layer Reachability Information field to
be determined as specified below.
この2八重奏の符号のない整数は八重奏における、Withdrawn Routes分野の全長を示します。 値は、Network Layer Reachability情報分野の長さが以下で指定されると決定しているのを許容しなければなりません。
A value of 0 indicates that no routes are being withdrawn from
service, and that the WITHDRAWN ROUTES field is not present in
this UPDATE message.
0の値はルートが全くサービスから引っ込められていなくて、またWITHDRAWN ROUTES分野がこのUPDATEメッセージに存在していないのを示します。
Withdrawn Routes:
よそよそしいルート:
This is a variable length field that contains a list of IP
address prefixes for the routes that are being withdrawn from
service. Each IP address prefix is encoded as a 2-tuple of the
form <length, prefix>, whose fields are described below:
これはサービスから引っ込められているルートへのIPアドレス接頭語のリストを含む可変長フィールドです。 それぞれのIPアドレス接頭語はフォーム<の長さの2-tuple、接頭語>としてコード化されます:(>の分野は以下で説明されます)。
Rekhter & Li [Page 11] RFC 1771 BGP-4 March 1995
Rekhterと李[11ページ]RFC1771BGP-1995年3月4日
+---------------------------+
| Length (1 octet) |
+---------------------------+
| Prefix (variable) |
+---------------------------+
+---------------------------+ | 長さ(1つの八重奏)| +---------------------------+ | 接頭語(変数)| +---------------------------+
The use and the meaning of these fields are as follows:
これらの分野の使用と意味は以下の通りです:
a) Length:
a) 長さ:
The Length field indicates the length in bits of the IP
address prefix. A length of zero indicates a prefix that
matches all IP addresses (with prefix, itself, of zero
octets).
Length分野はIPアドレス接頭語のビットの長さを示します。 ゼロの長さがすべてのIPアドレスに合っている接頭語を示す、(接頭語でそれ自体、八重奏がない、)
b) Prefix:
b) 以下を前に置いてください。
The Prefix field contains IP address prefixes followed by
enough trailing bits to make the end of the field fall on an
octet boundary. Note that the value of trailing bits is
irrelevant.
Prefix分野はIPアドレス接頭語を含んでいます、続いて、分野の端を八重奏境界に落ちさせることができるくらいの引きずっているビットを含みます。 引きずっているビットの価値が無関係であることに注意してください。
Total Path Attribute Length:
経路属性の長さを合計してください:
This 2-octet unsigned integer indicates the total length of the
Path Attributes field in octets. Its value must allow the
length of the Network Layer Reachability field to be determined
as specified below.
この2八重奏の符号のない整数は八重奏における、Path Attributes分野の全長を示します。 値は、Network Layer Reachability分野の長さが以下で指定されると決定しているのを許容しなければなりません。
A value of 0 indicates that no Network Layer Reachability
Information field is present in this UPDATE message.
0の値は、どんなNetwork Layer Reachability情報分野もこのUPDATEメッセージに存在していないのを示します。
Path Attributes:
経路属性:
A variable length sequence of path attributes is present in
every UPDATE. Each path attribute is a triple <attribute type,
attribute length, attribute value> of variable length.
経路属性の可変長系列はあらゆるUPDATEに存在しています。 各経路、属性はa三重の<属性タイプ、属性の長さ、可変長の属性値>です。
Attribute Type is a two-octet field that consists of the
Attribute Flags octet followed by the Attribute Type Code
octet.
属性TypeはAttribute Type Code八重奏があとに続いたAttribute Flags八重奏から成る2八重奏の分野です。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attr. Flags |Attr. Type Code|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attr。 旗|Attr。 コードをタイプしてください。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Rekhter & Li [Page 12] RFC 1771 BGP-4 March 1995
Rekhterと李[12ページ]RFC1771BGP-1995年3月4日
The high-order bit (bit 0) of the Attribute Flags octet is the
Optional bit. It defines whether the attribute is optional (if
set to 1) or well-known (if set to 0).
Attribute Flags八重奏の高位のビット(ビット0)はOptionalビットです。 それは、属性が任意であるか(1に設定されるなら)、またはよく知られるかを(0に設定されるなら)定義します。
The second high-order bit (bit 1) of the Attribute Flags octet
is the Transitive bit. It defines whether an optional
attribute is transitive (if set to 1) or non-transitive (if set
to 0). For well-known attributes, the Transitive bit must be
set to 1. (See Section 5 for a discussion of transitive
attributes.)
Attribute Flags八重奏の2番目の高位のビット(ビット1)はTransitiveビットです。 それは、任意の属性が遷移的であるか(1に設定されるなら)、または非遷移的であるかを(0に設定されるなら)定義します。 よく知られる属性において、Transitiveビットを1に設定しなければなりません。 (遷移的な属性の議論に関してセクション5を見てください。)
The third high-order bit (bit 2) of the Attribute Flags octet
is the Partial bit. It defines whether the information
contained in the optional transitive attribute is partial (if
set to 1) or complete (if set to 0). For well-known attributes
and for optional non-transitive attributes the Partial bit must
be set to 0.
Attribute Flags八重奏の3番目の高位のビット(ビット2)はPartialビットです。 それは、任意の遷移的な属性に含まれた情報が部分的であるか(1に設定されるなら)、または完全であるかを(0に設定されるなら)定義します。 よく知られる属性と任意の非他動詞属性において、Partialビットを0に設定しなければなりません。
The fourth high-order bit (bit 3) of the Attribute Flags octet
is the Extended Length bit. It defines whether the Attribute
Length is one octet (if set to 0) or two octets (if set to 1).
Extended Length may be used only if the length of the attribute
value is greater than 255 octets.
Attribute Flags八重奏の4番目の高位のビット(ビット3)はExtended Lengthビットです。 それは、Attribute Lengthが1つの八重奏(0に設定されるなら)かそれとも2つの八重奏(1に設定されるなら)であるかを定義します。 拡張Lengthは属性値の長さが255以上の八重奏である場合にだけ使用されるかもしれません。
The lower-order four bits of the Attribute Flags octet are .
unused. They must be zero (and must be ignored when received).
Attribute Flags八重奏の下層階級4ビットはそうです。. 未使用です。 それらはゼロであるに違いありません(そして、受け取ると、無視しなければなりません)。
The Attribute Type Code octet contains the Attribute Type Code.
Currently defined Attribute Type Codes are discussed in Section
5.
Attribute Type Code八重奏はAttribute Type Codeを含んでいます。 セクション5で現在定義されたAttribute Type Codesについて議論します。
If the Extended Length bit of the Attribute Flags octet is set
to 0, the third octet of the Path Attribute contains the length
of the attribute data in octets.
Attribute Flags八重奏のExtended Lengthビットが0に設定されるなら、Path Attributeの3番目の八重奏は八重奏における、属性データの長さを含んでいます。
If the Extended Length bit of the Attribute Flags octet is set
to 1, then the third and the fourth octets of the path
attribute contain the length of the attribute data in octets.
Attribute Flags八重奏のExtended Lengthビットが1に設定されるなら、経路属性の3番目と4番目の八重奏は八重奏における、属性データの長さを含んでいます。
The remaining octets of the Path Attribute represent the
attribute value and are interpreted according to the Attribute
Flags and the Attribute Type Code. The supported Attribute Type
Codes, their attribute values and uses are the following:
Path Attributeの残っている八重奏は、属性値を表して、Attribute FlagsとAttribute Type Codeによると、解釈されます。 彼らのサポートしているAttribute Type Codes、属性値、および用途は以下です:
Rekhter & Li [Page 13] RFC 1771 BGP-4 March 1995
Rekhterと李[13ページ]RFC1771BGP-1995年3月4日
a) ORIGIN (Type Code 1):
a) 発生源(コード1をタイプします):
ORIGIN is a well-known mandatory attribute that defines the
origin of the path information. The data octet can assume
the following values:
ORIGINは経路情報の発生源を定義するよく知られる義務的な属性です。 データ八重奏は以下の値を仮定できます:
Value Meaning
値の意味
0 IGP - Network Layer Reachability Information
is interior to the originating AS
0IGP--ネットワークLayer Reachability情報は起因しているASに内部です。
1 EGP - Network Layer Reachability Information
learned via EGP
1EGP--EGPを通して学習されたネットワークLayer Reachability情報
2 INCOMPLETE - Network Layer Reachability
Information learned by some other means
2INCOMPLETE--ある他の手段によって学習されたネットワークLayer Reachability情報
Its usage is defined in 5.1.1
用法が5.1で定義される、.1
b) AS_PATH (Type Code 2):
b) _経路(コード2をタイプする)として:
AS_PATH is a well-known mandatory attribute that is composed
of a sequence of AS path segments. Each AS path segment is
represented by a triple <path segment type, path segment
length, path segment value>.
AS_PATHはAS経路セグメントの系列で構成されるよく知られる義務的な属性です。 それぞれのAS経路セグメントは三重の<経路セグメントタイプ、経路セグメントの長さ、経路セグメント価値の>によって表されます。
Rekhter & Li [Page 14] RFC 1771 BGP-4 March 1995
Rekhterと李[14ページ]RFC1771BGP-1995年3月4日
The path segment type is a 1-octet long field with the
following values defined:
経路セグメントタイプは以下の値が定義されている1八重奏のロング・フィールドです:
Value Segment Type
値のセグメントタイプ
1 AS_SET: unordered set of ASs a route in the
UPDATE message has traversed
_としての1はセットしました: UPDATEメッセージのルートが横断したASsの順不同のセット
2 AS_SEQUENCE: ordered set of ASs a route in
the UPDATE message has traversed
2 _系列として: UPDATEメッセージのルートが横断したASsの順序集合
The path segment length is a 1-octet long field containing
the number of ASs in the path segment value field.
経路セグメントの長さは経路セグメント値の分野のASsの数を含む1八重奏のロング・フィールドです。
The path segment value field contains one or more AS
numbers, each encoded as a 2-octets long field.
経路セグメント値の分野は1つ以上のAS番号、2八重奏のロング・フィールドとしてコード化されたそれぞれを含んでいます。
Usage of this attribute is defined in 5.1.2.
この属性の用法は5.1で.2に定義されます。
c) NEXT_HOP (Type Code 3):
c) 次の_ホップ(コード3をタイプします):
This is a well-known mandatory attribute that defines the IP
address of the border router that should be used as the next
hop to the destinations listed in the Network Layer
Reachability field of the UPDATE message.
これは目的地への次のホップがUPDATEメッセージのNetwork Layer Reachability分野に記載したように使用されるべきである境界ルータのIPアドレスを定義するよく知られる義務的な属性です。
Usage of this attribute is defined in 5.1.3.
この属性の用法は5.1で.3に定義されます。
d) MULTI_EXIT_DISC (Type Code 4):
d) マルチ_出口_ディスク(コード4をタイプします):
This is an optional non-transitive attribute that is a four
octet non-negative integer. The value of this attribute may
be used by a BGP speaker's decision process to discriminate
among multiple exit points to a neighboring autonomous
system.
これは4八重奏非負の整数である任意の非他動詞属性です。 この属性の値はBGPスピーカーの決定プロセスによって使用されて、複数のエキジットポイントの中で隣接している自律システムに差別するかもしれません。
Its usage is defined in 5.1.4.
用法は5.1で.4に定義されます。
e) LOCAL_PREF (Type Code 5):
e) 地方の_PREF(コード5をタイプします):
LOCAL_PREF is a well-known discretionary attribute that is a
four octet non-negative integer. It is used by a BGP speaker
to inform other BGP speakers in its own autonomous system of
the originating speaker's degree of preference for an
advertised route. Usage of this attribute is described in
5.1.5.
LOCAL_PREFは4八重奏非負の整数であるよく知られる任意の属性です。 それは、起因しているスピーカーの広告を出しているルートのための好みの度合いに関するそれ自身の自律システムで他のBGPスピーカーに知らせるのにBGPスピーカーによって使用されます。 この属性の用法は5.1で.5に説明されます。
Rekhter & Li [Page 15] RFC 1771 BGP-4 March 1995
Rekhterと李[15ページ]RFC1771BGP-1995年3月4日
f) ATOMIC_AGGREGATE (Type Code 6)
f) 原子_集合(タイプコード6)
ATOMIC_AGGREGATE is a well-known discretionary attribute of
length 0. It is used by a BGP speaker to inform other BGP
speakers that the local system selected a less specific
route without selecting a more specific route which is
included in it. Usage of this attribute is described in
5.1.6.
ATOMIC_AGGREGATEは長さ0のよく知られる任意の属性です。 それは、ローカルシステムがそれに含まれているより特定のルートを選択しないでそれほど特定でないルートを選択したことを他のBGPスピーカーに知らせるのにBGPスピーカーによって使用されます。 この属性の用法は5.1で.6に説明されます。
g) AGGREGATOR (Type Code 7)
g) アグリゲータ(タイプコード7)
AGGREGATOR is an optional transitive attribute of length 6.
The attribute contains the last AS number that formed the
aggregate route (encoded as 2 octets), followed by the IP
address of the BGP speaker that formed the aggregate route
(encoded as 4 octets). Usage of this attribute is described
in 5.1.7
AGGREGATORは長さ6の任意の遷移的な属性です。 属性は集合ルート(4つの八重奏として、コード化される)を形成したBGPスピーカーのIPアドレスがあとに続いた集合ルート(2つの八重奏として、コード化される)を形成した最後のAS番号を含んでいます。 この属性の用法が5.1で説明される、.7
Network Layer Reachability Information:
ネットワーク層可到達性情報:
This variable length field contains a list of IP address
prefixes. The length in octets of the Network Layer
Reachability Information is not encoded explicitly, but can be
calculated as:
この可変長フィールドはIPアドレス接頭語のリストを含んでいます。 Network Layer Reachability情報の八重奏における長さについて明らかにコード化されませんが、以下として計算できます。
UPDATE message Length - 23 - Total Path Attributes Length -
Unfeasible Routes Length
UPDATEメッセージLength--23--総Path Attributes Length--実行不可能なRoutes Length
where UPDATE message Length is the value encoded in the fixed-
size BGP header, Total Path Attribute Length and Unfeasible
Routes Length are the values encoded in the variable part of
the UPDATE message, and 23 is a combined length of the fixed-
size BGP header, the Total Path Attribute Length field and the
Unfeasible Routes Length field.
UPDATEメッセージLengthが固定サイズBGPヘッダーでコード化された値であるところでは、Total Path Attribute LengthとUnfeasible Routes LengthはUPDATEメッセージの可変部分でコード化された値です、そして、23は固定サイズBGPヘッダー、Total Path Attribute Length分野、およびUnfeasible Routes Length分野の結合した長さです。
Reachability information is encoded as one or more 2-tuples of
the form <length, prefix>, whose fields are described below:
可到達性情報はフォーム<の長さの1 2-tuples、接頭語>としてコード化されます:(>の分野は以下で説明されます)。
+---------------------------+
| Length (1 octet) |
+---------------------------+
| Prefix (variable) |
+---------------------------+
+---------------------------+ | 長さ(1つの八重奏)| +---------------------------+ | 接頭語(変数)| +---------------------------+
Rekhter & Li [Page 16] RFC 1771 BGP-4 March 1995
Rekhterと李[16ページ]RFC1771BGP-1995年3月4日
The use and the meaning of these fields are as follows:
これらの分野の使用と意味は以下の通りです:
a) Length:
a) 長さ:
The Length field indicates the length in bits of the IP
address prefix. A length of zero indicates a prefix that
matches all IP addresses (with prefix, itself, of zero
octets).
Length分野はIPアドレス接頭語のビットの長さを示します。 ゼロの長さがすべてのIPアドレスに合っている接頭語を示す、(接頭語でそれ自体、八重奏がない、)
b) Prefix:
b) 以下を前に置いてください。
The Prefix field contains IP address prefixes followed by
enough trailing bits to make the end of the field fall on an
octet boundary. Note that the value of the trailing bits is
irrelevant.
Prefix分野はIPアドレス接頭語を含んでいます、続いて、分野の端を八重奏境界に落ちさせることができるくらいの引きずっているビットを含みます。 引きずっているビットの価値が無関係であることに注意してください。
The minimum length of the UPDATE message is 23 octets -- 19 octets for the fixed header + 2 octets for the Unfeasible Routes Length + 2 octets for the Total Path Attribute Length (the value of Unfeasible Routes Length is 0 and the value of Total Path Attribute Length is 0).
UPDATEメッセージの最小の長さは23の八重奏です--Total Path Attribute Length(Unfeasible Routes Lengthの値は0です、そして、Total Path Attribute Lengthの値は0である)のためのUnfeasible Routes Length+2つの八重奏のためのヘッダー+2つの固定八重奏のための19の八重奏。
An UPDATE message can advertise at most one route, which may be described by several path attributes. All path attributes contained in a given UPDATE messages apply to the destinations carried in the Network Layer Reachability Information field of the UPDATE message.
UPDATEメッセージは高々1つのルートの広告を出すことができます。(それは、いくつかの経路属性によって説明されるかもしれません)。 メッセージが目的地に当てはまる与えられたUPDATEに含まれたすべての経路属性がUPDATEメッセージのNetwork Layer Reachability情報分野で運ばれました。
An UPDATE message can list multiple routes to be withdrawn from service. Each such route is identified by its destination (expressed as an IP prefix), which unambiguously identifies the route in the context of the BGP speaker - BGP speaker connection to which it has been previously been advertised.
UPDATEメッセージは、サービスから引き下がるために複数のルートを記載できます。 BGPスピーカーの文脈で明白にルートを特定する目的地(IP接頭語として、言い表される)によってそのような各ルートは特定されます--以前にそれがどれであるかに広告に掲載されたBGPスピーカー接続。
An UPDATE message may advertise only routes to be withdrawn from service, in which case it will not include path attributes or Network Layer Reachability Information. Conversely, it may advertise only a feasible route, in which case the WITHDRAWN ROUTES field need not be present.
UPDATEメッセージはサービスから引き下がるためにルートだけの広告を出すかもしれません、その場合、それが経路属性かNetwork Layer Reachability情報を含まないでしょう。 逆に、可能なルートだけの広告を出すかもしれません、その場合、WITHDRAWN ROUTES分野は存在している必要はありません。
4.4 KEEPALIVE Message Format
4.4 KEEPALIVEメッセージ・フォーマット
BGP does not use any transport protocol-based keep-alive mechanism to determine if peers are reachable. Instead, KEEPALIVE messages are exchanged between peers often enough as not to cause the Hold Timer to expire. A reasonable maximum time between KEEPALIVE messages would be one third of the Hold Time interval. KEEPALIVE messages MUST NOT be sent more frequently than one per second. An implementation MAY adjust the rate at which it sends KEEPALIVE
BGPは、同輩が届くかどうか決定するのにどんな輸送のプロトコルベースの生きている生活費メカニズムも使用しません。 代わりに、Hold Timerが期限が切れることを引き起こさないで、同輩の間でKEEPALIVEメッセージをしばしば十分交換します。 KEEPALIVEメッセージの間の妥当な最大の時間はHold Time間隔の1/3でしょう。 1秒あたり1つより頻繁にKEEPALIVEメッセージを送ってはいけません。 実装はそれがKEEPALIVEを送るレートを調整するかもしれません。
Rekhter & Li [Page 17] RFC 1771 BGP-4 March 1995
Rekhterと李[17ページ]RFC1771BGP-1995年3月4日
messages as a function of the Hold Time interval.
Hold Time間隔の機能としてのメッセージ。
If the negotiated Hold Time interval is zero, then periodic KEEPALIVE messages MUST NOT be sent.
交渉されたHold Time間隔がゼロであるなら、周期的なKEEPALIVEメッセージを送ってはいけません。
KEEPALIVE message consists of only message header and has a length of 19 octets.
KEEPALIVEメッセージは、メッセージヘッダーだけから成って、19の八重奏の長さを持っています。
4.5 NOTIFICATION Message Format
4.5 通知メッセージ・フォーマット
A NOTIFICATION message is sent when an error condition is detected. The BGP connection is closed immediately after sending it.
エラー条件を検出するとき、NOTIFICATIONメッセージを送ります。 それを送る直後BGP接続は閉店します。
In addition to the fixed-size BGP header, the NOTIFICATION message contains the following fields:
固定サイズBGPヘッダーに加えて、NOTIFICATIONメッセージは以下の分野を含んでいます:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error code | Error subcode | Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | エラーコード| 誤り部分符号| データ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Error Code:
エラーコード:
This 1-octet unsigned integer indicates the type of
NOTIFICATION. The following Error Codes have been defined:
この1八重奏の符号のない整数はNOTIFICATIONのタイプを示します。 以下のError Codesは定義されました:
Error Code Symbolic Name Reference
エラーコード英字名参照
1 Message Header Error Section 6.1
1 メッセージヘッダー誤り部分6.1
2 OPEN Message Error Section 6.2
2 開いているメッセージ誤り部6.2
3 UPDATE Message Error Section 6.3
3 アップデートメッセージ誤り部6.3
4 Hold Timer Expired Section 6.5
4 保持のタイマの満期の部分6.5
5 Finite State Machine Error Section 6.6
5 有限状態機械誤り部分6.6
6 Cease Section 6.7
6はセクション6.7をやめます。
Error subcode:
誤り部分符号:
This 1-octet unsigned integer provides more specific
information about the nature of the reported error. Each Error
Code may have one or more Error Subcodes associated with it.
この1八重奏の符号のない整数は報告された誤りの本質の、より特定の情報を提供します。 各Error Codeには、それに関連している1Error Subcodesがあるかもしれません。
Rekhter & Li [Page 18] RFC 1771 BGP-4 March 1995
Rekhterと李[18ページ]RFC1771BGP-1995年3月4日
If no appropriate Error Subcode is defined, then a zero
(Unspecific) value is used for the Error Subcode field.
どんな適切なError Subcodeも定義されないなら、ゼロはError Subcode分野に使用されます(Unspecific)が、評価する。
Message Header Error subcodes:
メッセージHeader Error部分符号:
1 - Connection Not Synchronized.
2 - Bad Message Length.
3 - Bad Message Type.
1--接続は連動しませんでした。 2--悪いメッセージ長。 3--悪いメッセージタイプ。
OPEN Message Error subcodes:
オープンMessage Error部分符号:
1 - Unsupported Version Number.
2 - Bad Peer AS.
3 - Bad BGP Identifier. '
4 - Unsupported Optional Parameter.
5 - Authentication Failure.
6 - Unacceptable Hold Time.
1--サポートされないバージョン番号。 2--悪い同輩 3--悪いBGP識別子。 '4--サポートされない任意のパラメタ'。 5--認証失敗。 6--容認できない保持時間。
UPDATE Message Error subcodes:
UPDATE Message Error部分符号:
1 - Malformed Attribute List.
2 - Unrecognized Well-known Attribute.
3 - Missing Well-known Attribute.
4 - Attribute Flags Error.
5 - Attribute Length Error.
6 - Invalid ORIGIN Attribute
7 - AS Routing Loop.
8 - Invalid NEXT_HOP Attribute.
9 - Optional Attribute Error.
10 - Invalid Network Field.
11 - Malformed AS_PATH.
1--奇形の属性リスト。 2--認識されていないよく知られる属性。 3--よく知られる属性を逃します。 4--属性は誤りに旗を揚げさせます。 5--長さの誤りを結果と考えてください。 ルート設定としての6(無効の発生源属性7)は輪にされます。 8--次の病人_は属性を飛び越します。 9--任意の属性誤り。 10--無効のネットワーク分野。 11--_経路として、奇形です。
Data:
データ:
This variable-length field is used to diagnose the reason for
the NOTIFICATION. The contents of the Data field depend upon
the Error Code and Error Subcode. See Section 6 below for more
details.
この可変長の分野は、NOTIFICATIONの理由を診断するのに使用されます。 Data分野の内容はError CodeとError Subcodeによります。 その他の詳細に関して以下のセクション6を見てください。
Note that the length of the Data field can be determined from
the message Length field by the formula:
公式でメッセージLength分野からData分野の長さを測定できることに注意してください:
Message Length = 21 + Data Length
メッセージ長は21+データの長さと等しいです。
The minimum length of the NOTIFICATION message is 21 octets (including message header).
NOTIFICATIONメッセージの最小の長さは21の八重奏(メッセージヘッダーを含んでいて)です。
Rekhter & Li [Page 19] RFC 1771 BGP-4 March 1995
Rekhterと李[19ページ]RFC1771BGP-1995年3月4日
5. Path Attributes
5. 経路属性
This section discusses the path attributes of the UPDATE message.
このセクションはUPDATEメッセージの経路属性について論じます。
Path attributes fall into four separate categories:
経路属性は4つの別々のカテゴリになります:
1. Well-known mandatory.
2. Well-known discretionary.
3. Optional transitive.
4. Optional non-transitive.
1. よく知られる、義務的です。 2. よく知られる、任意です。 3. 任意の他動詞。 4. 任意の非他動詞。
Well-known attributes must be recognized by all BGP implementations. Some of these attributes are mandatory and must be included in every UPDATE message. Others are discretionary and may or may not be sent in a particular UPDATE message.
すべてのBGP実装でよく知られる属性を認識しなければなりません。 これらの属性のいくつかを義務的であり、あらゆるUPDATEメッセージに含まなければなりません。 他のものを任意であり、特定のUPDATEメッセージで送るかもしれません。
All well-known attributes must be passed along (after proper updating, if necessary) to other BGP peers.
すべてのよく知られる属性を他のBGP同輩に回さなければなりません(必要なら適切なアップデートの後に)。
In addition to well-known attributes, each path may contain one or more optional attributes. It is not required or expected that all BGP implementations support all optional attributes. The handling of an unrecognized optional attribute is determined by the setting of the Transitive bit in the attribute flags octet. Paths with unrecognized transitive optional attributes should be accepted. If a path with unrecognized transitive optional attribute is accepted and passed along to other BGP peers, then the unrecognized transitive optional attribute of that path must be passed along with the path to other BGP peers with the Partial bit in the Attribute Flags octet set to 1. If a path with recognized transitive optional attribute is accepted and passed along to other BGP peers and the Partial bit in the Attribute Flags octet is set to 1 by some previous AS, it is not set back to 0 by the current AS. Unrecognized non-transitive optional attributes must be quietly ignored and not passed along to other BGP peers.
よく知られる属性に加えて、各経路は1つ以上の任意の属性を含むかもしれません。 すべてのBGP実装がすべての任意の属性をサポートするというわけではないと必要であるか、または予想されます。 属性におけるTransitiveビットの設定で、八重奏に旗を揚げさせます認識されていない任意の属性の取り扱いが決定している。 認識されていない遷移的な任意の属性がある経路を受け入れるべきです。 認識されていない遷移的な任意の属性がある経路が他のBGP同輩に受け入れられて、回されるなら、経路と共にPartialビットで1に設定されたAttribute Flags八重奏でその経路の認識されていない遷移的な任意の属性を他のBGP同輩に渡さなければなりません。 認識された遷移的な任意の属性がある経路が他のBGP同輩に受け入れられて、回されて、Attribute Flags八重奏におけるPartialビットが前のいくつかのASによって1に設定されるなら、それは現在のASによって0に遅らせられません。 認識されていない非他動詞任意の属性を、静かに無視して、他のBGP同輩に回してはいけません。
New transitive optional attributes may be attached to the path by the originator or by any other AS in the path. If they are not attached by the originator, the Partial bit in the Attribute Flags octet is set to 1. The rules for attaching new non-transitive optional attributes will depend on the nature of the specific attribute. The documentation of each new non-transitive optional attribute will be expected to include such rules. (The description of the MULTI_EXIT_DISC attribute gives an example.) All optional attributes (both transitive and non-transitive) may be updated (if appropriate) by ASs in the path.
新しい遷移的な任意の属性は創始者か経路のいかなる他のASによっても経路に付けられるかもしれません。 それらが創始者によって付けられないなら、Attribute Flags八重奏におけるPartialビットは1に設定されます。 付けの新しい非他動詞任意の属性のための規則は特定の属性の本質によるでしょう。 それぞれの新しい非他動詞任意の属性のドキュメンテーションがそのような規則を含んでいると予想されるでしょう。 (MULTI_EXIT_DISC属性の記述は作例を示します。) すべての任意の属性(遷移的なものと同様に非遷移的な)が、経路のASsによるアップデートされるのと(適切。)であるかもしれません。
Rekhter & Li [Page 20] RFC 1771 BGP-4 March 1995
Rekhterと李[20ページ]RFC1771BGP-1995年3月4日
The sender of an UPDATE message should order path attributes within the UPDATE message in ascending order of attribute type. The receiver of an UPDATE message must be prepared to handle path attributes within the UPDATE message that are out of order.
UPDATEメッセージの送付者はUPDATEメッセージの中で属性タイプの昇順で経路属性を命令するべきです。 UPDATEメッセージの中の不適切な経路属性を扱うようにUPDATEメッセージの受信機を準備しなければなりません。
The same attribute cannot appear more than once within the Path Attributes field of a particular UPDATE message.
同じ属性は特定のUPDATEメッセージのPath Attributes分野の中で一度より多く見えることができません。
5.1 Path Attribute Usage
5.1 経路属性用法
The usage of each BGP path attributes is described in the following clauses.
BGP経路が結果と考えるそれぞれの用法は以下の節で説明されます。
5.1.1 ORIGIN
5.1.1 発生源
ORIGIN is a well-known mandatory attribute. The ORIGIN attribute shall be generated by the autonomous system that originates the associated routing information. It shall be included in the UPDATE messages of all BGP speakers that choose to propagate this information to other BGP speakers.
ORIGINはよく知られる義務的な属性です。 ORIGIN属性は関連ルーティング情報を溯源する自律システムによって生成されるものとします。 それは他のBGPスピーカーにこの情報を伝播するのを選ぶすべてのBGPスピーカーのUPDATEメッセージに含まれているものとします。
5.1.2 AS_PATH
5.1.2 _経路として
AS_PATH is a well-known mandatory attribute. This attribute identifies the autonomous systems through which routing information carried in this UPDATE message has passed. The components of this list can be AS_SETs or AS_SEQUENCEs.
AS_PATHはよく知られる義務的な属性です。 この属性はこのUPDATEメッセージで運ばれたルーティング情報が終わった自律システムを特定します。 このリストの成分は、AS_SETsかAS_SEQUENCEsであるかもしれません。
When a BGP speaker propagates a route which it has learned from another BGP speaker's UPDATE message, it shall modify the route's AS_PATH attribute based on the location of the BGP speaker to which the route will be sent:
BGPスピーカーがそれが別のBGPスピーカーのUPDATEメッセージから学んだルートを伝播するとき、ルートが送られるBGPスピーカーの位置に基づくルートのAS_PATH属性を変更するものとします:
a) When a given BGP speaker advertises the route to another BGP
speaker located in its own autonomous system, the advertising
speaker shall not modify the AS_PATH attribute associated with the
route.
a) 与えられたBGPスピーカーがそれ自身の自律システムに位置する別のBGPスピーカーにルートの広告を出すとき、広告スピーカーはルートに関連しているAS_PATH属性を変更しないものとします。
b) When a given BGP speaker advertises the route to a BGP speaker
located in a neighboring autonomous system, then the advertising
speaker shall update the AS_PATH attribute as follows:
b) 与えられたBGPスピーカーが隣接している自律システムに位置するBGPスピーカーにルートの広告を出すと、広告スピーカーは以下のAS_PATH属性をアップデートするものとします:
1) if the first path segment of the AS_PATH is of type
AS_SEQUENCE, the local system shall prepend its own AS number
as the last element of the sequence (put it in the leftmost
position).
1) タイプAS_SEQUENCEにAS_PATHの最初の経路セグメントがあると、ローカルシステムは系列(一番左位置にそれを入れる)の最後の原理としてのprependのそれ自身のAS番号があるでしょう。
Rekhter & Li [Page 21] RFC 1771 BGP-4 March 1995
Rekhterと李[21ページ]RFC1771BGP-1995年3月4日
2) if the first path segment of the AS_PATH is of type AS_SET,
the local system shall prepend a new path segment of type
AS_SEQUENCE to the AS_PATH, including its own AS number in that
segment.
2) タイプAS_SETにAS_PATHの最初の経路セグメントがあるなら、ローカルシステムはタイプAS_SEQUENCEの新しい経路セグメントをAS_PATHにprependするものとします、そのセグメントでそれ自身のAS番号を含んでいて。
When a BGP speaker originates a route then:
BGPスピーカーがその時ルートを溯源するとき:
a) the originating speaker shall include its own AS number in
the AS_PATH attribute of all UPDATE messages sent to BGP
speakers located in neighboring autonomous systems. (In this
case, the AS number of the originating speaker's autonomous
system will be the only entry in the AS_PATH attribute).
a) 起因しているスピーカーは隣接している自律システム(この場合起因しているスピーカーの自律システムの数がASにおける唯一のエントリーがPATHが結果と考える_であったならそうするAS)に位置するBGPスピーカーに送られたすべてのUPDATEメッセージのAS_PATH属性でそれ自身のAS番号を入れるものとします。
b) the originating speaker shall include an empty AS_PATH
attribute in all UPDATE messages sent to BGP speakers located
in its own autonomous system. (An empty AS_PATH attribute is
one whose length field contains the value zero).
b) 起因しているスピーカーはそれ自身の自律システムに位置するBGPスピーカーに送られたすべてのUPDATEメッセージで空のAS_PATH属性を入れるものとします。 (空のAS_PATH属性は長さの分野が値ゼロを含むものです。)
5.1.3 NEXT_HOP
5.1.3 次の_ホップ
The NEXT_HOP path attribute defines the IP address of the border router that should be used as the next hop to the destinations listed in the UPDATE message. If a border router belongs to the same AS as its peer, then the peer is an internal border router. Otherwise, it is an external border router. A BGP speaker can advertise any internal border router as the next hop provided that the interface associated with the IP address of this border router (as specified in the NEXT_HOP path attribute) shares a common subnet with both the local and remote BGP speakers. A BGP speaker can advertise any external border router as the next hop, provided that the IP address of this border router was learned from one of the BGP speaker's peers, and the interface associated with the IP address of this border router (as specified in the NEXT_HOP path attribute) shares a common subnet with the local and remote BGP speakers. A BGP speaker needs to be able to support disabling advertisement of external border routers.
ネクスト_HOP経路属性は目的地への次のホップがUPDATEメッセージに記載したように使用されるべきである境界ルータのIPアドレスを定義します。 境界ルータが同輩と同じASに属すなら、同輩は内部の境界ルータです。 さもなければ、それは外部の境界ルータです。 この境界ルータ(ネクスト_HOP経路属性で指定されるように)のIPアドレスに関連しているインタフェースが両方の地方の、そして、リモートなBGPスピーカーと一般的なサブネットを共有すれば、BGPスピーカーは次のホップとしてどんな内部の境界ルータも広告を出すことができます。 この境界ルータのIPアドレスがBGPスピーカーの同輩のひとりから学習されたならば、BGPスピーカーは次のホップとしてどんな外部の境界ルータも広告を出すことができます、そして、この境界ルータ(ネクスト_HOP経路属性で指定されるように)のIPアドレスに関連しているインタフェースは地方の、そして、リモートなBGPスピーカーと一般的なサブネットを共有します。 BGPスピーカーは、無効にするのが外部の境界ルータの広告であるとサポートすることができる必要があります。
A BGP speaker must never advertise an address of a peer to that peer as a NEXT_HOP, for a route that the speaker is originating. A BGP speaker must never install a route with itself as the next hop.
BGPスピーカーは決してネクスト_HOPとしてその同輩に同輩のアドレスの広告を出してはいけません、スピーカーが溯源しているルートに。 BGPスピーカーは次のホップとしてそれ自体でルートを決してインストールしてはいけません。
When a BGP speaker advertises the route to a BGP speaker located in its own autonomous system, the advertising speaker shall not modify the NEXT_HOP attribute associated with the route. When a BGP speaker receives the route via an internal link, it may forward packets to the NEXT_HOP address if the address contained in the attribute is on a common subnet with the local and remote BGP speakers.
BGPスピーカーがそれ自身の自律システムに位置するBGPスピーカーにルートの広告を出すとき、広告スピーカーはルートに関連しているネクスト_HOP属性を変更しないものとします。 BGPスピーカーが内部のリンクを通してルートを受け取るとき、属性に含まれたアドレスが地方の、そして、リモートなBGPスピーカーと共に一般的なサブネットにいるなら、それはネクスト_HOPアドレスにパケットを送るかもしれません。
Rekhter & Li [Page 22] RFC 1771 BGP-4 March 1995
Rekhterと李[22ページ]RFC1771BGP-1995年3月4日
5.1.4 MULTI_EXIT_DISC
5.1.4 マルチ_出口_ディスク
The MULTI_EXIT_DISC attribute may be used on external (inter-AS) links to discriminate among multiple exit or entry points to the same neighboring AS. The value of the MULTI_EXIT_DISC attribute is a four octet unsigned number which is called a metric. All other factors being equal, the exit or entry point with lower metric should be preferred. If received over external links, the MULTI_EXIT_DISC attribute may be propagated over internal links to other BGP speakers within the same AS. The MULTI_EXIT_DISC attribute is never propagated to other BGP speakers in neighboring AS's.
MULTI_EXIT_DISC属性が複数の出口の中で差別するのに外部(相互AS)のリンクの上に使用されるかもしれませんか、またはエントリーは同じ隣接しているASを示します。 MULTI_EXIT_DISC属性の値は4八重奏です。メートル法でaと呼ばれる符号のない数。 他のすべての要素が等しいか、出口またはエントリーが指すメートル法で下げられます。好まれるべきです。 外部のリンクの上に受け取るなら、同じASの中で他のBGPスピーカーへの内部のリンクの上にMULTI_EXIT_DISC属性を伝播するかもしれません。 The MULTI_EXIT_DISC attribute is never propagated to other BGP speakers in neighboring AS's.
5.1.5 LOCAL_PREF
5.1.5 地方の_PREF
LOCAL_PREF is a well-known discretionary attribute that shall be included in all UPDATE messages that a given BGP speaker sends to the other BGP speakers located in its own autonomous system. A BGP speaker shall calculate the degree of preference for each external route and include the degree of preference when advertising a route to its internal peers. The higher degree of preference should be preferred. A BGP speaker shall use the degree of preference learned via LOCAL_PREF in its decision process (see section 9.1.1).
LOCAL_PREFは与えられたBGPスピーカーがそれ自身の自律システムに位置する他のBGPスピーカーに発信するというすべてのUPDATEメッセージに含まれているものとするよく知られる任意の属性です。 内部の同輩にルートの広告を出すとき、BGPスピーカーは、各外部経路のための好みの度合いについて計算して、好みの度合いを入れるものとします。 より高度合いの好みは好まれるべきです。 BGPスピーカーは決定プロセスのLOCAL_PREFを通して学習された好みの度合いを使用するものとします(セクション9.1.1を見てください)。
A BGP speaker shall not include this attribute in UPDATE messages that it sends to BGP speakers located in a neighboring autonomous system. If it is contained in an UPDATE message that is received from a BGP speaker which is not located in the same autonomous system as the receiving speaker, then this attribute shall be ignored by the receiving speaker.
BGPスピーカーは隣接している自律システムに位置するBGPスピーカーに発信するというUPDATEメッセージでこの属性を入れないものとします。 それがBGPスピーカーから受け取られるUPDATEメッセージに含まれているなら、(受信スピーカーと同じ自律システムに位置していません)この属性は受信スピーカーによって無視されるものとします。
5.1.6 ATOMIC_AGGREGATE
5.1.6 原子_集合
ATOMIC_AGGREGATE is a well-known discretionary attribute. If a BGP speaker, when presented with a set of overlapping routes from one of its peers (see 9.1.4), selects the less specific route without selecting the more specific one, then the local system shall attach the ATOMIC_AGGREGATE attribute to the route when propagating it to other BGP speakers (if that attribute is not already present in the received less specific route). A BGP speaker that receives a route with the ATOMIC_AGGREGATE attribute shall not remove the attribute from the route when propagating it to other speakers. A BGP speaker that receives a route with the ATOMIC_AGGREGATE attribute shall not make any NLRI of that route more specific (as defined in 9.1.4) when advertising this route to other BGP speakers. A BGP speaker that receives a route with the ATOMIC_AGGREGATE attribute needs to be cognizant of the fact that the actual path to destinations, as specified in the NLRI of the route, while having the loop-free property, may traverse ASs that are not listed in the AS_PATH
ATOMIC_AGGREGATEはよく知られる任意の属性です。 いつがBGPスピーカーであるなら、同輩のひとりからルートを重ね合わせるセットに与えたか、(見る、9.1、.4、)、他のBGPスピーカーにそれを伝播するとき(その属性が容認されたそれほど特定でないルートに既に存在していないなら)特定のもの、ローカルシステムが付けるものとするその時を選択することのないATOMIC_AGGREGATEがルートの結果と考えるそれほど特定でないルートを選択します。 他のスピーカーにそれを伝播するとき、ATOMIC_AGGREGATE属性があるルートを受け取るBGPスピーカーはルートから属性を取り除かないものとします。 ATOMIC_AGGREGATE属性があるルートを受け取るBGPスピーカーがそのルートの少しのNLRIもより特定にしないものとする、(中で定義される、9.1、.4、)、他のBGPスピーカーにこのルートの広告を出すとき。 ATOMIC_AGGREGATE属性があるルートを受け取るBGPスピーカーは、目的地への無輪の特性を持っている間、ルートのNLRIで指定される実際の経路がAS_PATHに記載されていないASsを横断するかもしれないという事実において認識力がある必要があります。
Rekhter & Li [Page 23] RFC 1771 BGP-4 March 1995
Rekhterと李[23ページ]RFC1771BGP-1995年3月4日
attribute.
結果と考えます。
5.1.7 AGGREGATOR
5.1.7 アグリゲータ
AGGREGATOR is an optional transitive attribute which may be included in updates which are formed by aggregation (see Section 9.2.4.2). A BGP speaker which performs route aggregation may add the AGGREGATOR attribute which shall contain its own AS number and IP address.
セクション9.2を見てください。AGGREGATORが集合によって形成されるアップデートに含まれるかもしれない任意の遷移的な属性である、(.4 .2)。 ルート集合を実行するBGPスピーカーはそれ自身のAS番号とIPアドレスを含むものとするAGGREGATOR属性を加えるかもしれません。
6. BGP Error Handling.
6. BGPエラー処理。
This section describes actions to be taken when errors are detected while processing BGP messages.
このセクションは、BGPメッセージを処理している間誤りを検出するとき、取るために動作について説明します。
When any of the conditions described here are detected, a NOTIFICATION message with the indicated Error Code, Error Subcode, and Data fields is sent, and the BGP connection is closed. If no Error Subcode is specified, then a zero must be used.
ここで説明された状態のどれかを検出するとき、示されたError Code、Error Subcode、およびData分野があるNOTIFICATIONメッセージを送ります、そして、BGP接続は閉じます。 Error Subcodeが全く指定されないなら、ゼロを使用しなければなりません。
The phrase "the BGP connection is closed" means that the transport protocol connection has been closed and that all resources for that BGP connection have been deallocated. Routing table entries associated with the remote peer are marked as invalid. The fact that the routes have become invalid is passed to other BGP peers before the routes are deleted from the system.
接続が持っているトランスポート・プロトコルをある「BGP接続は閉じられること」が意味する句が閉じました、そして、そのBGP接続へのすべてのリソースが「反-割り当て」られました。 リモート同輩に関連している経路指定テーブルエントリーは無効であることが示されます。 ルートがシステムから削除される前にルートが無効になったという事実は他のBGP同輩に渡されます。
Unless specified explicitly, the Data field of the NOTIFICATION message that is sent to indicate an error is empty.
明らかに指定されない場合、誤りを示すために送られるNOTIFICATIONメッセージのData分野は人影がありません。
6.1 Message Header error handling.
6.1メッセージHeaderエラー処理。
All errors detected while processing the Message Header are indicated by sending the NOTIFICATION message with Error Code Message Header Error. The Error Subcode elaborates on the specific nature of the error.
Message Headerを処理している間に検出されたすべての誤りが、Error Code Message Header Errorと共にNOTIFICATIONメッセージを送ることによって、示されます。 Error Subcodeは誤りの特定の本質について詳しく説明します。
The expected value of the Marker field of the message header is all ones if the message type is OPEN. The expected value of the Marker field for all other types of BGP messages determined based on the presence of the Authentication Information Optional Parameter in the BGP OPEN message and the actual authentication mechanism (if the Authentication Information in the BGP OPEN message is present). If the Marker field of the message header is not the expected one, then a synchronization error has occurred and the Error Subcode is set to Connection Not Synchronized.
メッセージタイプがオープンであるなら、メッセージヘッダーのMarker分野の期待値はすべてものです。 他のすべてのタイプに関するBGPメッセージのためのMarker分野の期待値はAuthenticationの存在に基づいてBGP OPENメッセージと実際の認証機構で情報Optional Parameterを決定しました(BGP OPENメッセージのAuthentication情報が存在しているなら)。 メッセージヘッダーのMarker分野が予想されたものでないなら、同期誤りは発生しました、そして、Error SubcodeはConnection Not Synchronizedに用意ができています。
Rekhter & Li [Page 24] RFC 1771 BGP-4 March 1995
Rekhterと李[24ページ]RFC1771BGP-1995年3月4日
If the Length field of the message header is less than 19 or greater than 4096, or if the Length field of an OPEN message is less than the minimum length of the OPEN message, or if the Length field of an UPDATE message is less than the minimum length of the UPDATE message, or if the Length field of a KEEPALIVE message is not equal to 19, or if the Length field of a NOTIFICATION message is less than the minimum length of the NOTIFICATION message, then the Error Subcode is set to Bad Message Length. The Data field contains the erroneous Length field.
メッセージヘッダーのLength分野があるか、19以上より4096オープンメッセージのLength分野がオープンメッセージの最小の長さかそれともUPDATEメッセージのLength分野が、より少ないかどうかよりUPDATEメッセージの最小の長さある、KEEPALIVEメッセージのLength分野が19と等しくない、またはNOTIFICATIONメッセージのLength分野がNOTIFICATIONメッセージの最小の長さ以下であるなら、Error SubcodeはBad Message Lengthに用意ができています。 Data分野は誤ったLength分野を含んでいます。
If the Type field of the message header is not recognized, then the Error Subcode is set to Bad Message Type. The Data field contains the erroneous Type field.
メッセージヘッダーのType分野が認識されないなら、Error SubcodeはBad Message Typeに用意ができています。 Data分野は誤ったType分野を含んでいます。
6.2 OPEN message error handling.
6.2オープンメッセージエラー処理。
All errors detected while processing the OPEN message are indicated by sending the NOTIFICATION message with Error Code OPEN Message Error. The Error Subcode elaborates on the specific nature of the error.
オープンメッセージを処理している間に検出されたすべての誤りが、Error CodeオープンMessage Errorと共にNOTIFICATIONメッセージを送ることによって、示されます。 Error Subcodeは誤りの特定の本質について詳しく説明します。
If the version number contained in the Version field of the received OPEN message is not supported, then the Error Subcode is set to Unsupported Version Number. The Data field is a 2-octet unsigned integer, which indicates the largest locally supported version number less than the version the remote BGP peer bid (as indicated in the received OPEN message).
受信されたオープンメッセージのバージョン分野に保管されていたバージョン番号がサポートされないなら、Error SubcodeはUnsupportedバージョンNumberに用意ができています。 Data分野は2八重奏の符号のない整数です。(その符号のない整数はリモートBGP同輩が付けた(受信されたオープンメッセージにみられるように)バージョンほど示しません中で局所的にサポートしているバージョン番号最も大きい)。
If the Autonomous System field of the OPEN message is unacceptable, then the Error Subcode is set to Bad Peer AS. The determination of acceptable Autonomous System numbers is outside the scope of this protocol.
オープンメッセージのAutonomous System分野が容認できないなら、Error SubcodeはBad Peer ASに用意ができています。 このプロトコルの範囲の外に許容できるAutonomous System番号の決断があります。
If the Hold Time field of the OPEN message is unacceptable, then the Error Subcode MUST be set to Unacceptable Hold Time. An implementation MUST reject Hold Time values of one or two seconds. An implementation MAY reject any proposed Hold Time. An implementation which accepts a Hold Time MUST use the negotiated value for the Hold Time.
オープンメッセージのHold Time分野が容認できないなら、Error SubcodeはUnacceptable Hold Timeに用意ができなければなりません。 実装は1秒か2秒のHold Time値を拒絶しなければなりません。 実装はどんな提案されたHold Timeも拒絶するかもしれません。 Hold Timeを受け入れる実装はHold Timeに交渉された値を使用しなければなりません。
If the BGP Identifier field of the OPEN message is syntactically incorrect, then the Error Subcode is set to Bad BGP Identifier. Syntactic correctness means that the BGP Identifier field represents a valid IP host address.
オープンメッセージのBGP Identifier分野がシンタクス上不正確であるなら、Error SubcodeはBad BGP Identifierに用意ができています。 構文の正当性は、BGP Identifier分野が有効なIPホスト・アドレスを表すことを意味します。
If one of the Optional Parameters in the OPEN message is not recognized, then the Error Subcode is set to Unsupported Optional Parameters.
オープンメッセージのOptional Parametersの1つが認識されないなら、Error SubcodeはUnsupported Optional Parametersに用意ができています。
Rekhter & Li [Page 25] RFC 1771 BGP-4 March 1995
Rekhterと李[25ページ]RFC1771BGP-1995年3月4日
If the OPEN message carries Authentication Information (as an Optional Parameter), then the corresponding authentication procedure is invoked. If the authentication procedure (based on Authentication Code and Authentication Data) fails, then the Error Subcode is set to Authentication Failure.
オープンメッセージがAuthentication情報(Optional Parameterとしての)を運ぶなら、対応する認証手順は呼び出されます。 認証手順(Authentication CodeとAuthentication Dataに基づいている)が失敗するなら、Error SubcodeはAuthentication Failureに用意ができています。
6.3 UPDATE message error handling.
6.3UPDATEメッセージエラー処理。
All errors detected while processing the UPDATE message are indicated by sending the NOTIFICATION message with Error Code UPDATE Message Error. The error subcode elaborates on the specific nature of the error.
UPDATEメッセージを処理している間に検出されたすべての誤りが、Error Code UPDATE Message Errorと共にNOTIFICATIONメッセージを送ることによって、示されます。 誤り部分符号は誤りの特定の本質について詳しく説明します。
Error checking of an UPDATE message begins by examining the path attributes. If the Unfeasible Routes Length or Total Attribute Length is too large (i.e., if Unfeasible Routes Length + Total Attribute Length + 23 exceeds the message Length), then the Error Subcode is set to Malformed Attribute List.
UPDATEメッセージの誤りの照合は、経路属性を調べることによって、始まります。 Unfeasible Routes LengthかTotal Attribute Lengthが大き過ぎるなら(すなわち、Unfeasible Routes Length+合計Attribute Length+23がメッセージLengthを超えているなら)、Error SubcodeはMalformed Attribute Listに用意ができています。
If any recognized attribute has Attribute Flags that conflict with the Attribute Type Code, then the Error Subcode is set to Attribute Flags Error. The Data field contains the erroneous attribute (type, length and value).
どんな認識された属性にもAttribute Type Codeと衝突するAttribute Flagsがあるなら、Error SubcodeはAttribute Flags Errorに用意ができています。 Data分野は誤った属性(タイプ、長さ、および値)を含んでいます。
If any recognized attribute has Attribute Length that conflicts with the expected length (based on the attribute type code), then the Error Subcode is set to Attribute Length Error. The Data field contains the erroneous attribute (type, length and value).
どんな認識された属性にも予想された長さ(属性タイプコードに基づいている)と衝突するAttribute Lengthがあるなら、Error SubcodeはAttribute Length Errorに用意ができています。 Data分野は誤った属性(タイプ、長さ、および値)を含んでいます。
If any of the mandatory well-known attributes are not present, then the Error Subcode is set to Missing Well-known Attribute. The Data field contains the Attribute Type Code of the missing well-known attribute.
義務的なよく知られる属性のいずれも存在していないなら、Error SubcodeはMissing Wellによって知られているAttributeに用意ができています。 Data分野はなくなったよく知られる属性のAttribute Type Codeを含んでいます。
If any of the mandatory well-known attributes are not recognized, then the Error Subcode is set to Unrecognized Well-known Attribute. The Data field contains the unrecognized attribute (type, length and value).
義務的なよく知られる属性のいずれも認識されないなら、Error SubcodeはUnrecognized Wellによって知られているAttributeに用意ができています。 Data分野は認識されていない属性(タイプ、長さ、および値)を含んでいます。
If the ORIGIN attribute has an undefined value, then the Error Subcode is set to Invalid Origin Attribute. The Data field contains the unrecognized attribute (type, length and value).
未定義値がORIGIN属性にあるなら、Error SubcodeはInvalid Origin Attributeに用意ができています。 Data分野は認識されていない属性(タイプ、長さ、および値)を含んでいます。
If the NEXT_HOP attribute field is syntactically incorrect, then the Error Subcode is set to Invalid NEXT_HOP Attribute. The Data field contains the incorrect attribute (type, length and value). Syntactic correctness means that the NEXT_HOP attribute represents a valid IP host address. Semantic correctness applies only to the external BGP
ネクスト_HOP属性分野がシンタクス上不正確であるなら、Error SubcodeはInvalidネクスト_HOP Attributeに用意ができています。 Data分野は不正確な属性(タイプ、長さ、および値)を含んでいます。 構文の正当性は、ネクスト_HOP属性が有効なIPホスト・アドレスを表すことを意味します。 意味正当性は外部のBGPだけに適用されます。
Rekhter & Li [Page 26] RFC 1771 BGP-4 March 1995
Rekhterと李[26ページ]RFC1771BGP-1995年3月4日
links. It means that the interface associated with the IP address, as specified in the NEXT_HOP attribute, shares a common subnet with the receiving BGP speaker and is not the IP address of the receiving BGP speaker. If the NEXT_HOP attribute is semantically incorrect, the error should be logged, and the the route should be ignored. In this case, no NOTIFICATION message should be sent.
リンク。 それはネクスト_HOP属性で指定されるIPアドレスに関連しているインタフェースが受信BGPスピーカーと一般的なサブネットを共有して、受信BGPスピーカーのIPアドレスでないことを意味します。 ネクスト_HOP属性が意味的に不正確であるなら、誤りは登録されるべきです、そして、ルートは無視されるべきです。 この場合、NOTIFICATIONメッセージを全く送るべきではありません。
The AS_PATH attribute is checked for syntactic correctness. If the path is syntactically incorrect, then the Error Subcode is set to Malformed AS_PATH.
AS_PATH属性は構文の正当性がないかどうかチェックされます。 経路がシンタクス上不正確であるなら、Error SubcodeはMalformed AS_PATHに用意ができています。
If an optional attribute is recognized, then the value of this attribute is checked. If an error is detected, the attribute is discarded, and the Error Subcode is set to Optional Attribute Error. The Data field contains the attribute (type, length and value).
任意の属性が認識されるなら、この属性の値はチェックされます。 誤りが検出されるなら、属性は捨てられます、そして、Error SubcodeはOptional Attribute Errorに用意ができています。 Data分野は属性(タイプ、長さ、および値)を含んでいます。
If any attribute appears more than once in the UPDATE message, then the Error Subcode is set to Malformed Attribute List.
何か属性がUPDATEメッセージで一度より多く見えるなら、Error SubcodeはMalformed Attribute Listに用意ができています。
The NLRI field in the UPDATE message is checked for syntactic validity. If the field is syntactically incorrect, then the Error Subcode is set to Invalid Network Field.
UPDATEメッセージのNLRI分野は構文の正当性がないかどうかチェックされます。 分野がシンタクス上不正確であるなら、Error SubcodeはInvalid Network Fieldに用意ができています。
6.4 NOTIFICATION message error handling.
6.4NOTIFICATIONメッセージエラー処理。
If a peer sends a NOTIFICATION message, and there is an error in that message, there is unfortunately no means of reporting this error via a subsequent NOTIFICATION message. Any such error, such as an unrecognized Error Code or Error Subcode, should be noticed, logged locally, and brought to the attention of the administration of the peer. The means to do this, however, lies outside the scope of this document.
同輩がNOTIFICATIONメッセージを送って、そのメッセージに誤りがあれば、残念ながら、その後のNOTIFICATIONメッセージでこの誤りを報告する手段が全くありません。 認識されていないError CodeかError Subcodeなどのどんなそのような誤りも、同輩の管理の注意に気付かれていて、局所的に登録されて、もたらされるべきです。 このドキュメントの範囲の外にしかしながら、これをする手段があります。
6.5 Hold Timer Expired error handling.
6.5はTimer Expiredエラー処理を保持します。
If a system does not receive successive KEEPALIVE and/or UPDATE and/or NOTIFICATION messages within the period specified in the Hold Time field of the OPEN message, then the NOTIFICATION message with Hold Timer Expired Error Code must be sent and the BGP connection closed.
システムがオープンメッセージのHold Time分野で指定された期間中に連続したKEEPALIVE、UPDATE、そして/または、NOTIFICATIONメッセージを受け取らないなら、Hold Timer Expired Error CodeがあるNOTIFICATIONメッセージを送らなければなりませんでした、そして、BGP接続は閉じました。
6.6 Finite State Machine error handling.
6.6の有限州Machineエラー処理。
Any error detected by the BGP Finite State Machine (e.g., receipt of an unexpected event) is indicated by sending the NOTIFICATION message with Error Code Finite State Machine Error.
BGP Finite州Machine(例えば、予期せぬ出来事の領収書)によって検出されたどんな誤りも、Error Code Finite州Machine Errorと共にNOTIFICATIONメッセージを送ることによって、示されます。
Rekhter & Li [Page 27] RFC 1771 BGP-4 March 1995
Rekhterと李[27ページ]RFC1771BGP-1995年3月4日
6.7 Cease.
6.7はやみます。
In absence of any fatal errors (that are indicated in this section), a BGP peer may choose at any given time to close its BGP connection by sending the NOTIFICATION message with Error Code Cease. However, the Cease NOTIFICATION message must not be used when a fatal error indicated by this section does exist.
どんな致命的な誤り(それはこのセクションで示される)の欠如ではも、BGP同輩は、その時々でError Code Ceaseと共にNOTIFICATIONメッセージを送ることによってBGP接続を終えるのを選ぶかもしれません。 しかしながら、このセクションによって示された致命的な誤りが存在するとき、Cease NOTIFICATIONメッセージを使用してはいけません。
6.8 Connection collision detection.
6.8 接続衝突検出。
If a pair of BGP speakers try simultaneously to establish a TCP connection to each other, then two parallel connections between this pair of speakers might well be formed. We refer to this situation as connection collision. Clearly, one of these connections must be closed.
1組のBGPスピーカーが同時にTCP接続を互いに確立しようとするなら、この組のスピーカーの間の2人の並列接続がたぶん形成されるでしょう。 私たちはこの状況を接続衝突と呼びます。 明確に、これらの接続のひとりを閉じなければなりません。
Based on the value of the BGP Identifier a convention is established for detecting which BGP connection is to be preserved when a collision does occur. The convention is to compare the BGP Identifiers of the peers involved in the collision and to retain only the connection initiated by the BGP speaker with the higher-valued BGP Identifier.
BGP Identifierの値に基づいて、コンベンションは、衝突が起こるとき、保存されるためにBGP接続がどれであるかを検出するために設立されます。 コンベンションは、衝突にかかわる同輩のBGP Identifiersを比較して、より高く評価されたBGP Identifierと共にBGPスピーカーによって開始された接続だけを保有することになっています。
Upon receipt of an OPEN message, the local system must examine all of its connections that are in the OpenConfirm state. A BGP speaker may also examine connections in an OpenSent state if it knows the BGP Identifier of the peer by means outside of the protocol. If among these connections there is a connection to a remote BGP speaker whose BGP Identifier equals the one in the OPEN message, then the local system performs the following collision resolution procedure:
オープンメッセージを受け取り次第、ローカルシステムはOpenConfirm状態にある接続のすべてを調べなければなりません。 また、プロトコルの外で同輩について手段でBGP Identifierを知っているなら、BGPスピーカーはOpenSent状態で接続を調べるかもしれません。 これらの接続の中にBGP Identifierがオープンメッセージのものと等しいリモートBGPスピーカーとの接続があれば、ローカルシステムは以下の衝突解決手順を実行します:
1. The BGP Identifier of the local system is compared to the BGP
Identifier of the remote system (as specified in the OPEN
message).
1. ローカルシステムのBGP IdentifierはリモートシステムのBGP Identifierと比較されます(オープンメッセージで指定されるように)。
2. If the value of the local BGP Identifier is less than the
remote one, the local system closes BGP connection that already
exists (the one that is already in the OpenConfirm state), and
accepts BGP connection initiated by the remote system.
2. 地方のBGP Identifierの値がリモートもの以下であるなら、ローカルシステムは、既に存在するBGP接続(OpenConfirm状態に既にあるもの)を終えて、リモートシステムによって開始されたBGP接続を受け入れます。
3. Otherwise, the local system closes newly created BGP connection
(the one associated with the newly received OPEN message), and
continues to use the existing one (the one that is already in the
OpenConfirm state).
3. ローカルシステムは、新たに作成されたBGP接続(新たに受け取られたオープンメッセージに関連しているもの)を終えて、さもなければ、既存のものを使用し(OpenConfirm状態に既にあるもの)続けています。
Comparing BGP Identifiers is done by treating them as (4-octet
long) unsigned integers.
BGP Identifiersは、(4八重奏の長さ)符号のない整数として彼らを扱うことによって、比較されます。
Rekhter & Li [Page 28] RFC 1771 BGP-4 March 1995
Rekhterと李[28ページ]RFC1771BGP-1995年3月4日
A connection collision with an existing BGP connection that is in
Established states causes unconditional closing of the newly
created connection. Note that a connection collision cannot be
detected with connections that are in Idle, or Connect, or Active
states.
Established州にある既存のBGP接続との接続衝突は新たに作成された接続の無条件の閉鎖を引き起こします。 Idle、Connect、またはActive州にある接続と共に接続衝突を検出できないことに注意してください。
Closing the BGP connection (that results from the collision
resolution procedure) is accomplished by sending the NOTIFICATION
message with the Error Code Cease.
BGP接続(それは衝突解決手順から生じる)を終えるのは、Error Code Ceaseと共にNOTIFICATIONメッセージを送ることによって、実行されます。
7. BGP Version Negotiation.
7. BGPバージョン交渉。
BGP speakers may negotiate the version of the protocol by making multiple attempts to open a BGP connection, starting with the highest version number each supports. If an open attempt fails with an Error Code OPEN Message Error, and an Error Subcode Unsupported Version Number, then the BGP speaker has available the version number it tried, the version number its peer tried, the version number passed by its peer in the NOTIFICATION message, and the version numbers that it supports. If the two peers do support one or more common versions, then this will allow them to rapidly determine the highest common version. In order to support BGP version negotiation, future versions of BGP must retain the format of the OPEN and NOTIFICATION messages.
BGPスピーカーはBGP接続を開く複数の試みをすることによって、プロトコルのバージョンを交渉するかもしれません、それぞれがサポートする中で最も大きいバージョン番号から始まって。 開いている試みがError CodeオープンMessage Error、およびError Subcode UnsupportedバージョンNumberと共に失敗するなら、BGPスピーカーには、有効なそれが試みたバージョン番号、同輩が試みたバージョン番号、NOTIFICATIONメッセージの同輩によって通過されたバージョン番号、およびそれがサポートするバージョン番号があります。 2人の同輩が1つ以上の一般的なバージョンをサポートすると、これで、彼らは急速に最も高い一般的なバージョンを決定できるでしょう。 BGPがバージョン交渉であるとサポートするために、BGPの将来のバージョンはオープンとNOTIFICATIONメッセージの形式を保有しなければなりません。
8. BGP Finite State machine.
8. BGP Finite州マシン。
This section specifies BGP operation in terms of a Finite State Machine (FSM). Following is a brief summary and overview of BGP operations by state as determined by this FSM. A condensed version of the BGP FSM is found in Appendix 1.
このセクションはFinite州Machine(FSM)に関してBGP操作を指定します。 以下に、このFSMによって決定されるように状態によるBGP操作の簡潔な概要と概要があります。 BGP FSMの縮約版はAppendix1で見つけられます。
Initially BGP is in the Idle state.
初めは、BGPがIdle状態にあります。
Idle state:
状態を空費してください:
In this state BGP refuses all incoming BGP connections. No
resources are allocated to the peer. In response to the Start
event (initiated by either system or operator) the local system
initializes all BGP resources, starts the ConnectRetry timer,
initiates a transport connection to other BGP peer, while
listening for connection that may be initiated by the remote
BGP peer, and changes its state to Connect. The exact value of
the ConnectRetry timer is a local matter, but should be
sufficiently large to allow TCP initialization.
この状態では、BGPはすべての入って来るBGP接続を拒否します。 リソースを全く同輩に割り当てません。 Startイベント(システムかオペレータのどちらかによって開始される)に対応して、ローカルシステムは、ConnectにすべてのBGPリソースを初期化して、ConnectRetryタイマを始動して、リモートBGP同輩によって開始されるかもしれない接続の聞こうとしている間、他のBGP同輩に輸送接続を開始して、状態を変えます。 ConnectRetryタイマの正確な値は、地域にかかわる事柄ですが、TCPに初期化を許すことができるくらい大きいはずです。
If a BGP speaker detects an error, it shuts down the connection
and changes its state to Idle. Getting out of the Idle state
BGPスピーカーが誤りを検出するなら、それは接続と変化の下側にIdleへの状態を閉じます。 Idle状態から、出ます。
Rekhter & Li [Page 29] RFC 1771 BGP-4 March 1995
Rekhterと李[29ページ]RFC1771BGP-1995年3月4日
requires generation of the Start event. If such an event is
generated automatically, then persistent BGP errors may result
in persistent flapping of the speaker. To avoid such a
condition it is recommended that Start events should not be
generated immediately for a peer that was previously
transitioned to Idle due to an error. For a peer that was
previously transitioned to Idle due to an error, the time
between consecutive generation of Start events, if such events
are generated automatically, shall exponentially increase. The
value of the initial timer shall be 60 seconds. The time shall
be doubled for each consecutive retry.
Startイベントを世代に要求します。 そのようなイベントが自動的に生成されるなら、永続的なBGP誤りはスピーカーについて永続的なばたつくことをもたらすかもしれません。 そのような状態を避けるために、イベントがすぐ以前にそうであった同輩のために生成されるべきでないStartが誤りのためIdleに移行したのは、お勧めです。 誤りのために以前に移行しているIdleであった同輩に関しては、そのようなイベントが自動的に生成されるなら、連続した世代のStartイベントの間の時間は指数関数的に増加するものとします。 初期のタイマの値は60秒になるでしょう。 時間はそれぞれの連続した再試行のために倍にされるものとします。
Any other event received in the Idle state is ignored.
Idle状態に受け取られたいかなる他のイベントも無視されます。
Connect state:
状態をつなげてください:
In this state BGP is waiting for the transport protocol
connection to be completed.
この状態では、BGPは、輸送プロトコル接続が終了するのを待っています。
If the transport protocol connection succeeds, the local system
clears the ConnectRetry timer, completes initialization, sends
an OPEN message to its peer, and changes its state to OpenSent.
輸送プロトコル接続が成功するなら、ローカルシステムは、ConnectRetryタイマをきれいにして、初期化を終了して、オープンメッセージを同輩に送って、状態をOpenSentに変えます。
If the transport protocol connect fails (e.g., retransmission
timeout), the local system restarts the ConnectRetry timer,
continues to listen for a connection that may be initiated by
the remote BGP peer, and changes its state to Active state.
プロトコルが接続する輸送が(例えば、再送タイムアウト)に失敗するなら、ローカルシステムは、Active状態にConnectRetryタイマを再開して、リモートBGP同輩によって開始されるかもしれない接続の聞こうとし続けて、状態を変えます。
In response to the ConnectRetry timer expired event, the local
system restarts the ConnectRetry timer, initiates a transport
connection to other BGP peer, continues to listen for a
connection that may be initiated by the remote BGP peer, and
stays in the Connect state.
ConnectRetryタイマ満期のイベントに対応して、ローカルシステムは、ConnectRetryタイマを再開して、他のBGP同輩に輸送接続を開始して、リモートBGP同輩によって開始されるかもしれない接続の聞こうとし続けて、Connect状態にままでいます。
Start event is ignored in the Active state.
スタートイベントはActive状態で無視されます。
In response to any other event (initiated by either system or
operator), the local system releases all BGP resources
associated with this connection and changes its state to Idle.
いかなる他のイベント(システムかオペレータのどちらかによって開始される)に対応して、ローカルシステムは、この接続に関連しているすべてのBGPリソースを発表して、状態をIdleに変えます。
Active state:
活動的な州:
In this state BGP is trying to acquire a peer by initiating a
transport protocol connection.
この状態では、BGPは、輸送プロトコル接続を開始することによって、同輩を取得しようとしています。
If the transport protocol connection succeeds, the local system
clears the ConnectRetry timer, completes initialization, sends
an OPEN message to its peer, sets its Hold Timer to a large
輸送プロトコル接続が成功するなら、ローカルシステムは、同輩にConnectRetryタイマをきれいにして、初期化を終了して、オープンメッセージを送って、セットは多へのそのHold Timerです。
Rekhter & Li [Page 30] RFC 1771 BGP-4 March 1995
Rekhterと李[30ページ]RFC1771BGP-1995年3月4日
value, and changes its state to OpenSent. A Hold Timer value
of 4 minutes is suggested.
状態をOpenSentに評価して、変えます。 4分のHold Timer値は示されます。
In response to the ConnectRetry timer expired event, the local
system restarts the ConnectRetry timer, initiates a transport
connection to other BGP peer, continues to listen for a
connection that may be initiated by the remote BGP peer, and
changes its state to Connect.
ConnectRetryタイマ満期のイベントに対応して、ローカルシステムは、ConnectRetryタイマを再開して、他のBGP同輩に輸送接続を開始して、リモートBGP同輩によって開始されるかもしれない接続の聞こうとし続けて、状態をConnectに変えます。
If the local system detects that a remote peer is trying to
establish BGP connection to it, and the IP address of the
remote peer is not an expected one, the local system restarts
the ConnectRetry timer, rejects the attempted connection,
continues to listen for a connection that may be initiated by
the remote BGP peer, and stays in the Active state.
ローカルのシステムがそれを検出するならリモート同輩がBGP接続をそれに確立しようとしていて、リモート同輩のIPアドレスが予想されたものでなく、ローカルシステムは、ConnectRetryタイマを再開して、試みられた接続を拒絶して、リモートBGP同輩によって開始されるかもしれない接続の聞こうとし続けて、Active状態にいます。
Start event is ignored in the Active state.
スタートイベントはActive状態で無視されます。
In response to any other event (initiated by either system or
operator), the local system releases all BGP resources
associated with this connection and changes its state to Idle.
いかなる他のイベント(システムかオペレータのどちらかによって開始される)に対応して、ローカルシステムは、この接続に関連しているすべてのBGPリソースを発表して、状態をIdleに変えます。
OpenSent state:
OpenSent州:
In this state BGP waits for an OPEN message from its peer.
When an OPEN message is received, all fields are checked for
correctness. If the BGP message header checking or OPEN
message checking detects an error (see Section 6.2), or a
connection collision (see Section 6.8) the local system sends a
NOTIFICATION message and changes its state to Idle.
この状態では、BGPは同輩からのオープンメッセージを待っています。 オープンメッセージが受信されているとき、すべての分野が正当性がないかどうかチェックされます。 BGPメッセージヘッダーの照合かオープンメッセージの照合がローカルシステムがNOTIFICATIONメッセージを送る誤り(セクション6.2を見る)、または接続衝突(セクション6.8を見る)を検出して、状態をIdleに変えるなら。
If there are no errors in the OPEN message, BGP sends a
KEEPALIVE message and sets a KeepAlive timer. The Hold Timer,
which was originally set to a large value (see above), is
replaced with the negotiated Hold Time value (see section 4.2).
If the negotiated Hold Time value is zero, then the Hold Time
timer and KeepAlive timers are not started. If the value of
the Autonomous System field is the same as the local Autonomous
System number, then the connection is an "internal" connection;
otherwise, it is "external". (This will effect UPDATE
processing as described below.) Finally, the state is changed
to OpenConfirm.
オープンメッセージに誤りが全くなければ、BGPはKEEPALIVEメッセージを送って、KeepAliveタイマを設定します。 Hold Timer(元々、大きい値(上を見る)に用意ができていた)を交渉されたHold Time値に取り替えます(セクション4.2を見てください)。 交渉されたHold Time値がゼロであるなら、Hold TimeタイマとKeepAliveタイマは始動されません。 Autonomous System分野の値が地方のAutonomous System番号と同じであるなら、接続は「内部」の接続です。 さもなければ、それは「外部です」。 (これは以下で説明されるようにUPDATE処理に作用するでしょう。) 最終的に、状態はOpenConfirmに変わります。
If a disconnect notification is received from the underlying
transport protocol, the local system closes the BGP connection,
restarts the ConnectRetry timer, while continue listening for
connection that may be initiated by the remote BGP peer, and
goes into the Active state.
基本的なトランスポート・プロトコルから分離通知を受け取るなら、ローカルシステムがBGP接続を終えて、再開がConnectRetryタイマである、リモートBGP同輩によって開始されるかもしれなくて、Active状態に入る接続の聞こうとし続けてください。
Rekhter & Li [Page 31] RFC 1771 BGP-4 March 1995
Rekhterと李[31ページ]RFC1771BGP-1995年3月4日
If the Hold Timer expires, the local system sends NOTIFICATION
message with error code Hold Timer Expired and changes its
state to Idle.
Hold Timerが期限が切れるなら、ローカルシステムはエラーコードHold Timer Expiredと変化に伴うNOTIFICATIONメッセージにIdleへの状態を送ります。
In response to the Stop event (initiated by either system or
operator) the local system sends NOTIFICATION message with
Error Code Cease and changes its state to Idle.
Stopイベント(システムかオペレータのどちらかによって開始される)に対応して、ローカルシステムはError Code Ceaseと変化に伴うNOTIFICATIONメッセージにIdleへの状態を送ります。
Start event is ignored in the OpenSent state.
スタートイベントはOpenSent状態で無視されます。
In response to any other event the local system sends
NOTIFICATION message with Error Code Finite State Machine Error
and changes its state to Idle.
いかなる他のイベントに対応して、ローカルシステムはError Code Finite州Machine Errorと変化に伴うNOTIFICATIONメッセージにIdleへの状態を送ります。
Whenever BGP changes its state from OpenSent to Idle, it closes
the BGP (and transport-level) connection and releases all
resources associated with that connection.
BGPが状態をOpenSentからIdleに変えるときはいつも、それは、BGP(そして、輸送レベル)接続を終えて、その接続に関連しているすべてのリソースを発表します。
OpenConfirm state:
OpenConfirm州:
In this state BGP waits for a KEEPALIVE or NOTIFICATION
message.
この状態では、BGPはKEEPALIVEかNOTIFICATIONメッセージを待っています。
If the local system receives a KEEPALIVE message, it changes
its state to Established.
ローカルシステムがKEEPALIVEメッセージを受け取るなら、それは状態をEstablishedに変えます。
If the Hold Timer expires before a KEEPALIVE message is
received, the local system sends NOTIFICATION message with
error code Hold Timer Expired and changes its state to Idle.
KEEPALIVEメッセージが受信されている前にHold Timerが期限が切れるなら、ローカルシステムはエラーコードHold Timer Expiredと変化に伴うNOTIFICATIONメッセージにIdleへの状態を送ります。
If the local system receives a NOTIFICATION message, it changes
its state to Idle.
ローカルシステムがNOTIFICATIONメッセージを受け取るなら、それは状態をIdleに変えます。
If the KeepAlive timer expires, the local system sends a
KEEPALIVE message and restarts its KeepAlive timer.
KeepAliveタイマが期限が切れるなら、ローカルシステムは、KEEPALIVEメッセージを送って、KeepAliveタイマを再開します。
If a disconnect notification is received from the underlying
transport protocol, the local system changes its state to Idle.
基本的なトランスポート・プロトコルから分離通知を受け取るなら、ローカルシステムは状態をIdleに変えます。
In response to the Stop event (initiated by either system or
operator) the local system sends NOTIFICATION message with
Error Code Cease and changes its state to Idle.
Stop出来事(システムかオペレータのどちらかによって開始される)に対応して、ローカルシステムはError Code Ceaseと変化に伴うNOTIFICATIONメッセージにIdleへの状態を送ります。
Start event is ignored in the OpenConfirm state.
スタート出来事はOpenConfirm状態で無視されます。
In response to any other event the local system sends
NOTIFICATION message with Error Code Finite State Machine Error
and changes its state to Idle.
いかなる他の出来事に対応して、ローカルシステムはError Code Finite州Machine Errorと変化に伴うNOTIFICATIONメッセージにIdleへの状態を送ります。
Rekhter & Li [Page 32] RFC 1771 BGP-4 March 1995
Rekhterと李[32ページ]RFC1771BGP-1995年3月4日
Whenever BGP changes its state from OpenConfirm to Idle, it
closes the BGP (and transport-level) connection and releases
all resources associated with that connection.
BGPが状態をOpenConfirmからIdleに変えるときはいつも、それは、BGP(そして、輸送レベル)接続を終えて、その接続に関連しているすべてのリソースを発表します。
Established state:
設立された州:
In the Established state BGP can exchange UPDATE, NOTIFICATION,
and KEEPALIVE messages with its peer.
Established状態では、BGPは同輩と共にUPDATE、NOTIFICATION、およびKEEPALIVEメッセージを交換できます。
If the local system receives an UPDATE or KEEPALIVE message, it
restarts its Hold Timer, if the negotiated Hold Time value is
non-zero.
ローカルシステムがUPDATEかKEEPALIVEメッセージを受け取るなら、Hold Timerを再開します、交渉されたHold Time値が非ゼロであるなら。
If the local system receives a NOTIFICATION message, it changes
its state to Idle.
ローカルシステムがNOTIFICATIONメッセージを受け取るなら、それは状態をIdleに変えます。
If the local system receives an UPDATE message and the UPDATE
message error handling procedure (see Section 6.3) detects an
error, the local system sends a NOTIFICATION message and
changes its state to Idle.
ローカルシステムがUPDATEメッセージを受け取って、UPDATEメッセージエラー処理手順(セクション6.3を見る)が誤りを検出するなら、ローカルシステムは、NOTIFICATIONメッセージを送って、状態をIdleに変えます。
If a disconnect notification is received from the underlying
transport protocol, the local system changes its state to Idle.
基本的なトランスポート・プロトコルから分離通知を受け取るなら、ローカルシステムは状態をIdleに変えます。
If the Hold Timer expires, the local system sends a
NOTIFICATION message with Error Code Hold Timer Expired and
changes its state to Idle.
Hold Timerが期限が切れるなら、ローカルシステムはError Code Hold Timer Expiredと変化に伴うNOTIFICATIONメッセージにIdleへの状態を送ります。
If the KeepAlive timer expires, the local system sends a
KEEPALIVE message and restarts its KeepAlive timer.
KeepAliveタイマが期限が切れるなら、ローカルシステムは、KEEPALIVEメッセージを送って、KeepAliveタイマを再開します。
Each time the local system sends a KEEPALIVE or UPDATE message,
it restarts its KeepAlive timer, unless the negotiated Hold
Time value is zero.
ローカルシステムがKEEPALIVEかUPDATEメッセージを送る各回、KeepAliveタイマを再開します、交渉されたHold Time値がゼロでないなら。
In response to the Stop event (initiated by either system or
operator), the local system sends a NOTIFICATION message with
Error Code Cease and changes its state to Idle.
Stop出来事(システムかオペレータのどちらかによって開始される)に対応して、ローカルシステムはError Code Ceaseと変化に伴うNOTIFICATIONメッセージにIdleへの状態を送ります。
Start event is ignored in the Established state.
スタート出来事はEstablished状態で無視されます。
In response to any other event, the local system sends
NOTIFICATION message with Error Code Finite State Machine Error
and changes its state to Idle.
いかなる他の出来事に対応して、ローカルシステムはError Code Finite州Machine Errorと変化に伴うNOTIFICATIONメッセージにIdleへの状態を送ります。
Whenever BGP changes its state from Established to Idle, it
closes the BGP (and transport-level) connection, releases all
resources associated with that connection, and deletes all
BGPが状態をEstablishedからIdleに変えるときはいつも、それは、BGP(そして、輸送レベル)接続を終えて、その接続に関連しているすべてのリソースを発表して、すべてを削除します。
Rekhter & Li [Page 33] RFC 1771 BGP-4 March 1995
Rekhterと李[33ページ]RFC1771BGP-1995年3月4日
routes derived from that connection.
ルートがその接続に由来していました。
9. UPDATE Message Handling
9. アップデートメッセージハンドリング
An UPDATE message may be received only in the Established state. When an UPDATE message is received, each field is checked for validity as specified in Section 6.3.
Established状態だけにUPDATEメッセージを受け取るかもしれません。 UPDATEメッセージが受信されているとき、各分野はセクション6.3における指定されるとしての正当性がないかどうかチェックされます。
If an optional non-transitive attribute is unrecognized, it is quietly ignored. If an optional transitive attribute is unrecognized, the Partial bit (the third high-order bit) in the attribute flags octet is set to 1, and the attribute is retained for propagation to other BGP speakers.
任意の非他動詞属性が認識されていないなら、それは静かに無視されます。 任意の他動な属性が認識されていないなら、Partialは八重奏が設定される属性旗における(3番目の高位のビット)1に噛み付きました、そして、属性は伝播のために他のBGPスピーカーに保有されます。
If an optional attribute is recognized, and has a valid value, then, depending on the type of the optional attribute, it is processed locally, retained, and updated, if necessary, for possible propagation to other BGP speakers.
任意の属性が認識されて、有効値を持っているなら、タイプに頼っていて、任意の属性では、それを局所的に処理して、保有して、必要なら、アップデートします、他のBGPスピーカーへの可能な伝播のために。
If the UPDATE message contains a non-empty WITHDRAWN ROUTES field, the previously advertised routes whose destinations (expressed as IP prefixes) contained in this field shall be removed from the Adj-RIB- In. This BGP speaker shall run its Decision Process since the previously advertised route is not longer available for use.
UPDATEメッセージが非人影のないWITHDRAWN ROUTES分野を含んでいるなら、目的地(IP接頭語として、言い表される)が中にこの分野を含んだ以前に広告を出したルートはAdj-RIBから中に取り外されるものとします。 以前に広告を出したルートが使用に利用可能な状態で、より長くないので、このBGPスピーカーはDecision Processを走らせるものとします。
If the UPDATE message contains a feasible route, it shall be placed in the appropriate Adj-RIB-In, and the following additional actions shall be taken:
UPDATEメッセージが可能なルートを含んでいるなら、中の適切なAdj-RIBにそれを置くものとします、そして、以下の追加行動を取るものとします:
i) If its Network Layer Reachability Information (NLRI) is identical to the one of a route currently stored in the Adj-RIB-In, then the new route shall replace the older route in the Adj-RIB-In, thus implicitly withdrawing the older route from service. The BGP speaker shall run its Decision Process since the older route is no longer available for use.
i) Network Layer Reachability情報(NLRI)が現在中のAdj-RIBに格納されているルートの1つと同じであるなら、新しいルートは中のAdj-RIBの、より古いルートを置き換えるものとします、その結果、それとなく、サービスから、より古いルートを引っ込めます。 より古いルートがもう使用に利用可能でないので、BGPスピーカーはDecision Processを走らせるものとします。
ii) If the new route is an overlapping route that is included (see 9.1.4) in an earlier route contained in the Adj-RIB-In, the BGP speaker shall run its Decision Process since the more specific route has implicitly made a portion of the less specific route unavailable for use.
ii) 新しいルートが含まれている重なっているルートである、(見る、9.1、.4、)、Adj-RIB-コネに含まれた以前のルートでは、それほど特定でないルートの一部が、より特定のルートでそれとなく使用を入手できなくなったので、BGPスピーカーはDecision Processを走らせるものとします。
iii) If the new route has identical path attributes to an earlier route contained in the Adj-RIB-In, and is more specific (see 9.1.4) than the earlier route, no further actions are necessary.
iii) 新しいルートがAdj-RIB-コネに含まれた以前のルートに同じ経路属性を持って、より特定である、(見る、9.1、.4、)、以前が発送するより遠い動作が必要です。
iv) If the new route has NLRI that is not present in any of the routes currently stored in the Adj-RIB-In, then the new route shall
iv) 新しいルートが現在中のAdj-RIBに格納されているルートのどれかに存在していないNLRIを持っていると、新しいルートはそうするでしょう。
Rekhter & Li [Page 34] RFC 1771 BGP-4 March 1995
Rekhterと李[34ページ]RFC1771BGP-1995年3月4日
be placed in the Adj-RIB-In. The BGP speaker shall run its Decision Process.
中のAdj-RIBに置かれてください。 BGPスピーカーはDecision Processを走らせるものとします。
v) If the new route is an overlapping route that is less specific (see 9.1.4) than an earlier route contained in the Adj-RIB-In, the BGP speaker shall run its Decision Process on the set of destinations described only by the less specific route.
v) 新しいルートがそれほど特定でない重なっているルートである、(見る、9.1、.4、)、BGPスピーカーは以前のルートがAdj-RIB-コネに含んだより単にそれほど特定でないルートで説明された目的地のセットのDecision Processを走らせるものとします。
9.1 Decision Process
9.1 決定の過程
The Decision Process selects routes for subsequent advertisement by applying the policies in the local Policy Information Base (PIB) to the routes stored in its Adj-RIB-In. The output of the Decision Process is the set of routes that will be advertised to all peers; the selected routes will be stored in the local speaker's Adj-RIB- Out.
Decision Processは、地方のPolicy Information基地(PIB)の中の方針を中のAdj-RIBに格納されたルートに適用することによって、その後の広告のためのルートを選択します。 Decision Processの出力はすべての同輩に広告に掲載されているルートのセットです。 選択されたルートは地元のスピーカーのAdj-RIBに外に格納されるでしょう。
The selection process is formalized by defining a function that takes the attribute of a given route as an argument and returns a non- negative integer denoting the degree of preference for the route. The function that calculates the degree of preference for a given route shall not use as its inputs any of the following: the existence of other routes, the non-existence of other routes, or the path attributes of other routes. Route selection then consists of individual application of the degree of preference function to each feasible route, followed by the choice of the one with the highest degree of preference.
選択の過程は、議論として与えられたルートの属性をみなして、好みの度合いを指示する非負の整数をルートに返す機能を定義することによって、正式にされます。 与えられたルートのための好みの度合いについて計算する機能は入力として以下のいずれも使用しないものとします: 他のルートの存在、他のルートの非存在、または他のルートの経路属性。 そして、ルート選択は最も高度の好みによるものの選択があとに続いたそれぞれの可能なルートに選択関数の度合いの個々の適用から成ります。
The Decision Process operates on routes contained in each Adj-RIB-In, and is responsible for:
Decision Processは中の各Adj-RIBに含まれたルートを作動させて、以下に責任があります。
- selection of routes to be advertised to BGP speakers located in
the local speaker's autonomous system
- 地元のスピーカーの自律システムに位置するBGPスピーカーに広告を出すべきルートの品揃え
- selection of routes to be advertised to BGP speakers located in
neighboring autonomous systems
- 隣接している自律システムに位置するBGPスピーカーに広告を出すべきルートの品揃え
- route aggregation and route information reduction
- ルート集合と経由地案内減少
The Decision Process takes place in three distinct phases, each triggered by a different event:
Decision Processは異なった出来事によってそれぞれ引き起こされた3つの異なったフェーズで行われます:
a) Phase 1 is responsible for calculating the degree of preference
for each route received from a BGP speaker located in a
neighboring autonomous system, and for advertising to the other
BGP speakers in the local autonomous system the routes that have
the highest degree of preference for each distinct destination.
a) フェーズ1は隣接している自律システムに位置するBGPスピーカーから受け取られた各ルートのための好みの度合いについて計算して、地方の自律システムにそれぞれの異なった目的地のための最も高度の好みを持っているルートの他のBGPスピーカーに広告を出すのに原因となります。
Rekhter & Li [Page 35] RFC 1771 BGP-4 March 1995
Rekhterと李[35ページ]RFC1771BGP-1995年3月4日
b) Phase 2 is invoked on completion of phase 1. It is responsible
for choosing the best route out of all those available for each
distinct destination, and for installing each chosen route into
the appropriate Loc-RIB.
b) フェーズ2はフェーズ1の完成のときに呼び出されます。 それはそれぞれの異なった目的地へのすべての利用可能なそれらから最も良いルートを選んで、それぞれの選ばれたルートを適切なLoc-RIBにインストールするのに責任があります。
c) Phase 3 is invoked after the Loc-RIB has been modified. It is
responsible for disseminating routes in the Loc-RIB to each peer
located in a neighboring autonomous system, according to the
policies contained in the PIB. Route aggregation and information
reduction can optionally be performed within this phase.
c) Loc-RIBが変更された後にフェーズ3は呼び出されます。 それは隣接している自律システムに位置する各同輩にLoc-RIBのルートを広めるのに責任があります、PIBに含まれた方針によると。 このフェーズの中で任意にルート集合と情報減少を実行できます。
9.1.1 Phase 1: Calculation of Degree of Preference
9.1.1 フェーズ1: 好みの度合いの計算
The Phase 1 decision function shall be invoked whenever the local BGP speaker receives an UPDATE message from a peer located in a neighboring autonomous system that advertises a new route, a replacement route, or a withdrawn route.
地元のBGPスピーカーが新しいルート、交換ルート、またはよそよそしいルートの広告を出す隣接している自律システムに位置する同輩からUPDATEメッセージを受け取るときはいつも、Phaseの1つの決定の機能は呼び出されるものとします。
The Phase 1 decision function is a separate process which completes when it has no further work to do.
Phase1決定関数はいつを完成する別々の過程です。それはこれ以上仕事がありません。
The Phase 1 decision function shall lock an Adj-RIB-In prior to operating on any route contained within it, and shall unlock it after operating on all new or unfeasible routes contained within it.
Phaseの1つの決定の機能は、それの中に含まれたどんなルートも作動させる前に中のAdj-RIBをロックして、それの中に含まれたすべての新しいか実行不可能なルートを作動させた後に、それをアンロックするものとします。
For each newly received or replacement feasible route, the local BGP speaker shall determine a degree of preference. If the route is learned from a BGP speaker in the local autonomous system, either the value of the LOCAL_PREF attribute shall be taken as the degree of preference, or the local system shall compute the degree of preference of the route based on preconfigured policy information. If the route is learned from a BGP speaker in a neighboring autonomous system, then the degree of preference shall be computed based on preconfigured policy information. The exact nature of this policy information and the computation involved is a local matter. The local speaker shall then run the internal update process of 9.2.1 to select and advertise the most preferable route.
新たに受け取られたそれぞれか交換の可能なルートと、地元のBGPスピーカーは1段階の好みを決定するものとします。 ルートが地方の自律システムのBGPスピーカーから学習されるなら、LOCAL_PREF属性の値が好みの度合いとしてみなされるものとしますか、またはローカルシステムはあらかじめ設定された方針情報に基づくルートの好みの度合いを計算するものとします。 ルートが隣接している自律システムのBGPスピーカーから学習されるなら、好みの度合いはあらかじめ設定された方針情報に基づいて計算されるものとします。 情報と計算がかかわったこの方針の正確な本質は地域にかかわる事柄です。 地元のスピーカーはそうするでしょう、次に、9.2の内部の更新処理を走らせてください。.1 最も望ましいルートを選択して、広告を出すために。
9.1.2 Phase 2: Route Selection
9.1.2 フェーズ2: ルート選択
The Phase 2 decision function shall be invoked on completion of Phase 1. The Phase 2 function is a separate process which completes when it has no further work to do. The Phase 2 process shall consider all routes that are present in the Adj-RIBs-In, including those received from BGP speakers located in its own autonomous system and those received from BGP speakers located in neighboring autonomous systems.
Phase2決定関数はPhase1の完成のときに呼び出されるものとします。 Phase2機能はいつを完成する別々の過程です。それはこれ以上仕事がありません。 Phase2の過程は中のAdj-RIBsですべての存在しているルートを考えるものとします、それ自身の自律システムに位置するBGPスピーカーと隣接している自律システムに位置するBGPスピーカーから受け取られたものから受け取られたものを含んでいて。
Rekhter & Li [Page 36] RFC 1771 BGP-4 March 1995
Rekhterと李[36ページ]RFC1771BGP-1995年3月4日
The Phase 2 decision function shall be blocked from running while the Phase 3 decision function is in process. The Phase 2 function shall lock all Adj-RIBs-In prior to commencing its function, and shall unlock them on completion.
Phase2決定関数はPhase3決定関数が過程にある間、走るのが妨げられるものとします。 Phase2機能は、機能を始める前に中のすべてのAdj-RIBsをロックして、完成のときに彼らをアンロックするものとします。
If the NEXT_HOP attribute of a BGP route depicts an address to which the local BGP speaker doesn't have a route in its Loc-RIB, the BGP route SHOULD be excluded from the Phase 2 decision function.
BGPルートのネクスト_HOP属性が地元のBGPスピーカーがそうしないアドレスについて表現するなら、Loc-RIBのルート、BGPルートSHOULDはPhase2決定関数から除かれましたか?
For each set of destinations for which a feasible route exists in the Adj-RIBs-In, the local BGP speaker shall identify the route that has:
可能なルートが中のAdj-RIBsに存在するそれぞれのセットの目的地に関しては、地元のBGPスピーカーは以下を持っているルートを特定するものとします。
a) the highest degree of preference of any route to the same set
of destinations, or
またはa) 最も高度の同じセットの目的地へのどんなルートの好み、も。
b) is the only route to that destination, or
またはb) その目的地には唯一のルートがある。
c) is selected as a result of the Phase 2 tie breaking rules
specified in 9.1.2.1.
c)は選択されました、その結果、Phase2繋がりでは、壊れている規則が9.1で.1に.2を指定しました。
The local speaker SHALL then install that route in the Loc-RIB, replacing any route to the same destination that is currently being held in the Loc-RIB. The local speaker MUST determine the immediate next hop to the address depicted by the NEXT_HOP attribute of the selected route by performing a lookup in the IGP and selecting one of the possible paths in the IGP. This immediate next hop MUST be used when installing the selected route in the Loc-RIB. If the route to the address depicted by the NEXT_HOP attribute changes such that the immediate next hop changes, route selection should be recalculated as specified above.
次に、地方のスピーカーSHALLはそのルートをLoc-RIBにインストールします、現在Loc-RIBで開催されているのと同じ目的地にどんなルートも置き換えて。 地元のスピーカーは選択されたルートのネクスト_HOP属性によってIGPでルックアップを実行して、IGPで可能な経路の1つを選択することによって表現されたアドレスに次の即座のホップを決定しなければなりません。 選択されたルートをLoc-RIBにインストールするとき、この次の即座のホップを使用しなければなりません。 ネクスト_HOP属性によって表現されたアドレスへのルートが次の即座のホップが変化するようなものを変えるなら、ルート選択は上で指定されるとして再計算されるべきです。
Unfeasible routes shall be removed from the Loc-RIB, and corresponding unfeasible routes shall then be removed from the Adj- RIBs-In.
実行不可能なルートはLoc-RIBから取り外されるものとします、そして、次に、対応する実行不可能なルートは中のAdj- RIBsから取り外されるものとします。
9.1.2.1 Breaking Ties (Phase 2)
9.1.2.1 壊れている結びつき(フェーズ2)
In its Adj-RIBs-In a BGP speaker may have several routes to the same destination that have the same degree of preference. The local speaker can select only one of these routes for inclusion in the associated Loc-RIB. The local speaker considers all equally preferable routes, both those received from BGP speakers located in neighboring autonomous systems, and those received from other BGP speakers located in the local speaker's autonomous system.
中のAdj-RIBsでは、BGPスピーカーは同じ度の好みを持っている数個のルートを同じ目的地に持っているかもしれません。 地元のスピーカーは関連Loc-RIBでの包含のためのこれらのルートの1つしか選択できません。 地元のスピーカーは地元のスピーカーの自律システムに位置する他のBGPスピーカーから受け取られたすべての等しく望ましいルート、隣接している自律システムに位置するBGPスピーカーから受け取られた両方のもの、およびものを考えます。
The following tie-breaking procedure assumes that for each candidate route all the BGP speakers within an autonomous system can ascertain the cost of a path (interior distance) to the address depicted by the
以下の繋がりを壊す手順は、それぞれの候補ルートのために、自律システムの中のすべてのBGPスピーカーが経路(内部の距離)の費用を表現されたアドレスに確かめることができると仮定します。
Rekhter & Li [Page 37] RFC 1771 BGP-4 March 1995
Rekhterと李[37ページ]RFC1771BGP-1995年3月4日
NEXT_HOP attribute of the route. Ties shall be broken according to the following algorithm:
HOPが結果と考えるルートのネクスト_。 以下のアルゴリズムによると、結びつきは壊れるでしょう:
a) If the local system is configured to take into account
MULTI_EXIT_DISC, and the candidate routes differ in their
MULTI_EXIT_DISC attribute, select the route that has the lowest
value of the MULTI_EXIT_DISC attribute.
a) ローカルシステムがMULTI_EXIT_DISCを考慮に入れるために構成されて、候補ルートがそれらのMULTI_EXIT_DISC属性において異なるなら、MULTI_EXIT_DISC属性の最も低い値を持っているルートを選択してください。
b) Otherwise, select the route that has the lowest cost (interior
distance) to the entity depicted by the NEXT_HOP attribute of the
route. If there are several routes with the same cost, then the
tie-breaking shall be broken as follows:
b) さもなければ、ルートのネクスト_HOP属性で、実体への最も低い費用(内部の距離)について表現するルートを選択してください。 同じ費用がある数個のルートがあると、繋がり壊すのは以下の通り壊れるでしょう:
- if at least one of the candidate routes was advertised by the
BGP speaker in a neighboring autonomous system, select the
route that was advertised by the BGP speaker in a neighboring
autonomous system whose BGP Identifier has the lowest value
among all other BGP speakers in neighboring autonomous systems;
- 少なくとも候補ルートの1つが隣接している自律システムのBGPスピーカーによって広告に掲載されたなら、BGP Identifierが隣接している自律システムに他のすべてのBGPスピーカーの中に持っている中で値最も低い隣接している自律システムのBGPスピーカーによって広告に掲載されたルートを選択してください。
- otherwise, select the route that was advertised by the BGP
speaker whose BGP Identifier has the lowest value.
- さもなければ、BGP Identifierが持っている中で値最も低いBGPスピーカーによって広告に掲載されたルートを選択してください。
9.1.3 Phase 3: Route Dissemination
9.1.3 フェーズ3: ルート普及
The Phase 3 decision function shall be invoked on completion of Phase 2, or when any of the following events occur:
Phase3決定関数はPhase2の完成のときに呼び出されるものとして、以下の出来事のどれかがいつ起こるかをそうされます:
a) when routes in a Loc-RIB to local destinations have changed
a) 地方へのLoc-RIBのルートであるときに、目的地は変化しました。
b) when locally generated routes learned by means outside of BGP
have changed
b) 局所的に発生したルートが手段で学んだときには、BGPの外で変化してください、そうした。
c) when a new BGP speaker - BGP speaker connection has been
established
c) 新しいBGPスピーカーであるときに、確立します、--BGPスピーカー接続は確立されました。
The Phase 3 function is a separate process which completes when it has no further work to do. The Phase 3 Routing Decision function shall be blocked from running while the Phase 2 decision function is in process.
Phase3機能はいつを完成する別々の過程です。それはこれ以上仕事がありません。 Phase3ルート設定Decision機能はPhase2決定関数が過程にある間、走るのが妨げられるものとします。
All routes in the Loc-RIB shall be processed into a corresponding entry in the associated Adj-RIBs-Out. Route aggregation and information reduction techniques (see 9.2.4.1) may optionally be applied.
Loc-RIBのすべてのルートが外の関連Adj-RIBsで対応するエントリーに処理されるものとします。 見てください。集合と情報減少のテクニックを発送してください、(9.2 .4 適用されていて、.1は)任意にそうしてもよいです。
For the benefit of future support of inter-AS multicast capabilities, a BGP speaker that participates in inter-AS multicast routing shall advertise a route it receives from one of its external peers and if
そして相互ASマルチキャスト能力の今後のサポートの恩恵のために、相互ASマルチキャストルーティングに参加するBGPスピーカーがそれが外部の同輩のひとりから受けるルートの広告を出すものとする。
Rekhter & Li [Page 38] RFC 1771 BGP-4 March 1995
Rekhterと李[38ページ]RFC1771BGP-1995年3月4日
it installs it in its Loc-RIB, it shall advertise it back to the peer from which the route was received. For a BGP speaker that does not participate in inter-AS multicast routing such an advertisement is optional. When doing such an advertisement, the NEXT_HOP attribute should be set to the address of the peer. An implementation may also optimize such an advertisement by truncating information in the AS_PATH attribute to include only its own AS number and that of the peer that advertised the route (such truncation requires the ORIGIN attribute to be set to INCOMPLETE). In addition an implementation is not required to pass optional or discretionary path attributes with such an advertisement.
それはそれをLoc-RIBにインストールして、ルートが受け取られた同輩にそれの広告を出して戻すものとします。 相互ASマルチキャストルーティングに参加しないBGPスピーカーにとって、そのような広告は任意です。 そのような広告をするとき、ネクスト_HOP属性は同輩のアドレスに設定されるべきです。 また、実現は、ルートの広告を出した同輩のそれ自身だけのAS番号とものを含むようにAS_PATH属性における情報に先端を切らせることによって、そのような広告を最適化するかもしれません(そのようなトランケーションは、ORIGIN属性がINCOMPLETEに設定されるのを必要とします)。 さらに、実現は、そのような広告で任意の、または、任意の経路属性を通過するのに必要ではありません。
When the updating of the Adj-RIBs-Out and the Forwarding Information Base (FIB) is complete, the local BGP speaker shall run the external update process of 9.2.2.
外のAdj-RIBsとForwarding Information基地(FIB)のアップデートが完全であるときに、地元のBGPスピーカーは9.2の外部の更新処理を.2に走らせるものとします。
9.1.4 Overlapping Routes
9.1.4 ルートを重ね合わせること。
A BGP speaker may transmit routes with overlapping Network Layer Reachability Information (NLRI) to another BGP speaker. NLRI overlap occurs when a set of destinations are identified in non-matching multiple routes. Since BGP encodes NLRI using IP prefixes, overlap will always exhibit subset relationships. A route describing a smaller set of destinations (a longer prefix) is said to be more specific than a route describing a larger set of destinations (a shorted prefix); similarly, a route describing a larger set of destinations (a shorter prefix) is said to be less specific than a route describing a smaller set of destinations (a longer prefix).
BGPスピーカーはNetwork Layer Reachability情報(NLRI)を別のBGPスピーカーに重ね合わせるのにルートを伝えるかもしれません。 1セットの目的地が複数の非合っているルートで特定されるとき、NLRIオーバラップは起こります。 BGPがIP接頭語を使用することでNLRIをコード化するので、オーバラップはいつも部分集合関係を示すでしょう。 より小さいセットの目的地(より長い接頭語)について説明するルートは、より大きいセットの目的地(ショートしている接頭語)について説明するルートより特有であると言われています。 同様に、より大きいセットの目的地(より短い接頭語)について説明するルートは、より小さいセットの目的地(より長い接頭語)について説明するルートほど特有でないと言われています。
The precedence relationship effectively decomposes less specific routes into two parts:
事実上、先行関係はそれほど特定でないルートを2つの部品に分解します:
- a set of destinations described only by the less specific
route, and
- そして単にそれほど特定でないルートで説明された、1セットの目的地。
- a set of destinations described by the overlap of the less
specific and the more specific routes
- それほど特定でないルートと、より特定のルートのオーバラップによって説明された1セットの目的地
When overlapping routes are present in the same Adj-RIB-In, the more specific route shall take precedence, in order from more specific to least specific.
重なっているルートが中の同じAdj-RIBに存在しているとき、より特定のルートは優先するものとします、より特定であるのから最も特有にならないまでのオーダーで。
The set of destinations described by the overlap represents a portion of the less specific route that is feasible, but is not currently in use. If a more specific route is later withdrawn, the set of destinations described by the overlap will still be reachable using the less specific route.
オーバラップによって説明された目的地のセットは可能な、しかし、現在使用中でないそれほど特定でないルートの一部を表します。 より特定のルートが後で引っ込められると、オーバラップによって説明された目的地のセットは、それほど特定でないルートを使用することでまだ届いているでしょう。
Rekhter & Li [Page 39] RFC 1771 BGP-4 March 1995
Rekhterと李[39ページ]RFC1771BGP-1995年3月4日
If a BGP speaker receives overlapping routes, the Decision Process shall take into account the semantics of the overlapping routes. In particular, if a BGP speaker accepts the less specific route while rejecting the more specific route from the same peer, then the destinations represented by the overlap may not forward along the ASs listed in the AS_PATH attribute of that route. Therefore, a BGP speaker has the following choices:
BGPスピーカーがルートを重ね合わせながら受信するなら、Decision Processは重なっているルートの意味論を考慮に入れるものとします。 BGPスピーカーが同じ同輩から、より特定のルートを拒絶している間、それほど特定でないルートを受け入れるなら、特に、オーバラップによって表された目的地はずっとそのルートのAS_PATH属性で記載されたASsを進めないかもしれません。 したがって、BGPスピーカーには、以下の選択があります:
a) Install both the less and the more specific routes
a) 少しもよりそして、より特定のルートをインストールしないでください。
b) Install the more specific route only
b) より特定のルートだけをインストールしてください。
c) Install the non-overlapping part of the less specific
route only (that implies de-aggregation)
c) それほど特定でないルートの非重なっている部分だけをインストールしてください。(それは反-集合を含意します)
d) Aggregate the two routes and install the aggregated route
d) 2つのルートに集めてください、そして、集められたルートをインストールしてください。
e) Install the less specific route only
e) それほど特定でないルートだけをインストールしてください。
f) Install neither route
f) どちらのルートもインストールしないでください。
If a BGP speaker chooses e), then it should add ATOMIC_AGGREGATE attribute to the route. A route that carries ATOMIC_AGGREGATE attribute can not be de-aggregated. That is, the NLRI of this route can not be made more specific. Forwarding along such a route does not guarantee that IP packets will actually traverse only ASs listed in the AS_PATH attribute of the route. If a BGP speaker chooses a), it must not advertise the more general route without the more specific route.
BGPスピーカーがe)を選ぶなら、それはAGGREGATEがルートの結果と考えるATOMIC_を加えるべきです。 反-AGGREGATEが結果と考えるATOMIC_を運ぶルートは集めることができません。 すなわち、このルートのNLRIをより特定にすることができません。 そのようなルートに沿った推進は、IPパケットが実際にルートのAS_PATH属性で記載されたASsだけを横断するのを保証しません。 BGPスピーカーがa)を選ぶなら、それは、より特定のルートなしで、より一般的なルートの広告を出してはいけません。
9.2 Update-Send Process
9.2は過程をアップデートして送ります。
The Update-Send process is responsible for advertising UPDATE messages to all peers. For example, it distributes the routes chosen by the Decision Process to other BGP speakers which may be located in either the same autonomous system or a neighboring autonomous system. rules for information exchange between BGP speakers located in different autonomous systems are given in 9.2.2; rules for information exchange between BGP speakers located in the same autonomous system are given in 9.2.1.
すべての同輩にとって、Update発信している過程は広告UPDATEメッセージに原因となります。 例えば、それは他のBGPスピーカーへの同じ自律システムか隣接している自律システムのどちらかに位置するかもしれないDecision Processによって選ばれたルートを分配します。異なった自律システムに位置するBGPスピーカーの間の情報交換のための規則を中に与える、9.2、.2、。 9.2で.1に同じ自律システムに位置するBGPスピーカーの間の情報交換のための規則を与えます。
Distribution of routing information between a set of BGP speakers, all of which are located in the same autonomous system, is referred to as internal distribution.
1セットのBGPスピーカーの間のルーティング情報の分配は内部の分配と呼ばれます。そのすべてが同じ自律システムに位置しています。
Rekhter & Li [Page 40] RFC 1771 BGP-4 March 1995
Rekhterと李[40ページ]RFC1771BGP-1995年3月4日
9.2.1 Internal Updates
9.2.1 内部のアップデート
The Internal update process is concerned with the distribution of routing information to BGP speakers located in the local speaker's autonomous system.
Internal更新処理は地元のスピーカーの自律システムに位置しているBGPスピーカーへのルーティング情報の分配に関係があります。
When a BGP speaker receives an UPDATE message from another BGP speaker located in its own autonomous system, the receiving BGP speaker shall not re-distribute the routing information contained in that UPDATE message to other BGP speakers located in its own autonomous system.
BGPスピーカーがそれ自身の自律システムに位置する別のBGPスピーカーからUPDATEメッセージを受け取るとき、受信BGPスピーカーはそのUPDATEメッセージにそれ自身の自律システムに位置する他のBGPスピーカーに含まれたルーティング情報を再配付しないものとします。
When a BGP speaker receives a new route from a BGP speaker in a neighboring autonomous system, it shall advertise that route to all other BGP speakers in its autonomous system by means of an UPDATE message if any of the following conditions occur:
BGPスピーカーが隣接している自律システムのBGPスピーカーから新しいルートを受け取るとき、以下の条件のどれかが現れるなら、UPDATEメッセージによって自律システムの他のすべてのBGPスピーカーにそのルートの広告を出すものとします:
1) the degree of preference assigned to the newly received route
by the local BGP speaker is higher than the degree of preference
that the local speaker has assigned to other routes that have been
received from BGP speakers in neighboring autonomous systems, or
または1) 隣接している自律システムにおいて地元のBGPスピーカーによって新たに受け取られたルートに割り当てられた好みの度が地元のスピーカーがBGPスピーカーから受け取られた他のルートに割り当てた好みの度合いより高である。
2) there are no other routes that have been received from BGP
speakers in neighboring autonomous systems, or
または2) BGPスピーカーから受け取られた他のルートが全く隣接している自律システムにない。
3) the newly received route is selected as a result of breaking a
tie between several routes which have the highest degree of
preference, and the same destination (the tie-breaking procedure
is specified in 9.2.1.1).
3) 最も高度の好み、および同じ目的地を持っている数個のルートの間の繋がりを壊すことの結果、新たに受け取られたルートが選択される、(繋がりを壊す手順が指定される、9.2、.1、.1、)
When a BGP speaker receives an UPDATE message with a non-empty WITHDRAWN ROUTES field, it shall remove from its Adj-RIB-In all routes whose destinations was carried in this field (as IP prefixes). The speaker shall take the following additional steps:
BGPスピーカーが非人影のないWITHDRAWN ROUTES分野でUPDATEメッセージを受け取るとき、それは目的地がこの分野(IP接頭語としての)で運ばれた全部でAdj-RIBルートから取り外されるものとします。 スピーカーは追加方法を以下まで採るものとします:
1) if the corresponding feasible route had not been previously
advertised, then no further action is necessary
1) 対応する可能なルートが以前に広告に掲載されていなかったなら、さらなるどんな動作も必要ではありません。
2) if the corresponding feasible route had been previously
advertised, then:
2) 次に、対応する可能なルートが以前に広告に掲載されたなら:
i) if a new route is selected for advertisement that has the
same Network Layer Reachability Information as the unfeasible
routes, then the local BGP speaker shall advertise the
replacement route
i) 新しいルートが実行不可能なルートと同じNetwork Layer Reachability情報を持っている広告のために選択されるなら、地元のBGPスピーカーは交換ルートの広告を出すものとします。
ii) if a replacement route is not available for advertisement,
then the BGP speaker shall include the destinations of the
ii)、交換ルートは広告、BGPスピーカーが目的地を含むものとするその時に利用可能ではありません。
Rekhter & Li [Page 41] RFC 1771 BGP-4 March 1995
Rekhterと李[41ページ]RFC1771BGP-1995年3月4日
unfeasible route (in form of IP prefixes) in the WITHDRAWN
ROUTES field of an UPDATE message, and shall send this message
to each peer to whom it had previously advertised the
corresponding feasible route.
WITHDRAWN ROUTESの実行不可能なルート(IP接頭語の形の)は、それが以前に対応する可能なルートの広告を出した各同輩へのこのメッセージをUPDATEメッセージをさばいて、送るものとします。
All feasible routes which are advertised shall be placed in the appropriate Adj-RIBs-Out, and all unfeasible routes which are advertised shall be removed from the Adj-RIBs-Out.
広告に掲載されているすべての可能なルートが外の適切なAdj-RIBsに置かれるものとします、そして、広告に掲載されているすべての実行不可能なルートが外のAdj-RIBsから取り外されるものとします。
9.2.1.1 Breaking Ties (Internal Updates)
9.2.1.1 壊れている結びつき(内部のアップデート)
If a local BGP speaker has connections to several BGP speakers in neighboring autonomous systems, there will be multiple Adj-RIBs-In associated with these peers. These Adj-RIBs-In might contain several equally preferable routes to the same destination, all of which were advertised by BGP speakers located in neighboring autonomous systems. The local BGP speaker shall select one of these routes according to the following rules:
数人のBGPスピーカーに地元のBGPスピーカーが隣接している自律システムに接続がいると、中にこれらの同輩に関連している複数のAdj-RIBsがあるでしょう。 中のこれらのAdj-RIBsはそれのすべてが隣接している自律システムに位置するBGPスピーカーによって広告に掲載されたのと同じ目的地に数個の等しく望ましいルートを含むかもしれません。以下の規則に従って、地元のBGPスピーカーはこれらのルートの1つを選択するものとします:
a) If the candidate route differ only in their NEXT_HOP and
MULTI_EXIT_DISC attributes, and the local system is configured to
take into account MULTI_EXIT_DISC attribute, select the routes
that has the lowest value of the MULTI_EXIT_DISC attribute.
a) 候補ルートがそれらのネクスト_HOPとMULTI_EXIT_DISC属性だけにおいて異なって、ローカルシステムがDISCが結果と考えるMULTI_EXIT_を考慮に入れるために構成されるなら、MULTI_EXIT_DISC属性の最も低い値を持っているルートを選択してください。
b) If the local system can ascertain the cost of a path to the
entity depicted by the NEXT_HOP attribute of the candidate route,
select the route with the lowest cost.
b) ローカルシステムが候補ルートのネクスト_HOP属性によって表現された実体に経路の費用を確かめることができるなら、最も低い費用があるルートを選択してください。
c) In all other cases, select the route that was advertised by the
BGP speaker whose BGP Identifier has the lowest value.
c) 他のすべての場合では、BGP Identifierが持っている中で値最も低いBGPスピーカーによって広告に掲載されたルートを選択してください。
9.2.2 External Updates
9.2.2 外部のアップデート
The external update process is concerned with the distribution of routing information to BGP speakers located in neighboring autonomous systems. As part of Phase 3 route selection process, the BGP speaker has updated its Adj-RIBs-Out and its Forwarding Table. All newly installed routes and all newly unfeasible routes for which there is no replacement route shall be advertised to BGP speakers located in neighboring autonomous systems by means of UPDATE message.
外部の更新処理は隣接している自律システムに位置しているBGPスピーカーへのルーティング情報の分配に関係があります。Phase3ルート選択の過程の一部として、BGPスピーカーは外のAdj-RIBsとそのForwarding Tableをアップデートしました。 交換ルートが全くないすべての新たにインストールされたルートとすべての新たに実行不可能なルートのUPDATEメッセージによる隣接している自律システムに位置するBGPスピーカーに広告を出すものとします。
Any routes in the Loc-RIB marked as unfeasible shall be removed. Changes to the reachable destinations within its own autonomous system shall also be advertised in an UPDATE message.
実行不可能であるとしてマークされたLoc-RIBのどんなルートも取り外されるものとします。 また、UPDATEメッセージにそれ自身の自律システムの中の届いている目的地への変化の広告を出すものとします。
Rekhter & Li [Page 42] RFC 1771 BGP-4 March 1995
Rekhterと李[42ページ]RFC1771BGP-1995年3月4日
9.2.3 Controlling Routing Traffic Overhead
9.2.3 ルート設定交通オーバーヘッドを制御すること。
The BGP protocol constrains the amount of routing traffic (that is, UPDATE messages) in order to limit both the link bandwidth needed to advertise UPDATE messages and the processing power needed by the Decision Process to digest the information contained in the UPDATE messages.
BGPプロトコルは、情報がUPDATEメッセージに含んだUPDATEメッセージの広告を出すのに必要であるリンク帯域幅と読みこなすためにDecision Processによって必要とされた処理能力の両方を制限するためにルーティング交通(すなわち、UPDATEメッセージ)の量を抑制します。
9.2.3.1 Frequency of Route Advertisement
9.2.3.1 ルート広告の頻度
The parameter MinRouteAdvertisementInterval determines the minimum amount of time that must elapse between advertisement of routes to a particular destination from a single BGP speaker. This rate limiting procedure applies on a per-destination basis, although the value of MinRouteAdvertisementInterval is set on a per BGP peer basis.
パラメタMinRouteAdvertisementIntervalはルートの広告の間で独身のBGPスピーカーから特定の目的地に経過しなければならない最小の時間を決定します。 手順を制限するこのレートが1目的地あたり1個のベースで適用されます、MinRouteAdvertisementIntervalの値はBGP同輩基礎あたりのaに設定されますが。
Two UPDATE messages sent from a single BGP speaker that advertise feasible routes to some common set of destinations received from BGP speakers in neighboring autonomous systems must be separated by at least MinRouteAdvertisementInterval. Clearly, this can only be achieved precisely by keeping a separate timer for each common set of destinations. This would be unwarranted overhead. Any technique which ensures that the interval between two UPDATE messages sent from a single BGP speaker that advertise feasible routes to some common set of destinations received from BGP speakers in neighboring autonomous systems will be at least MinRouteAdvertisementInterval, and will also ensure a constant upper bound on the interval is acceptable.
少なくともMinRouteAdvertisementIntervalは可能なルートの広告を出す独身のBGPスピーカーから隣接している自律システムのBGPスピーカーから受け取られた何らかの一般的なセットの目的地に送られた2つのUPDATEメッセージを切り離さなければなりません。 明確に、まさにそれぞれの一般的なセットの目的地に別々のタイマを保つことによって、これを達成できるだけです。 これは保証のないオーバーヘッドでしょう。 2つのUPDATEメッセージの間隔が可能なルートの広告を出す独身のBGPスピーカーから隣接している自律システムのBGPスピーカーから受け取られた何らかの一般的なセットの目的地まで発信したのを確実にするどんなテクニックも、少なくともMinRouteAdvertisementIntervalであり、また、間隔の一定の上限が許容できるのを確実にするでしょう。
Since fast convergence is needed within an autonomous system, this procedure does not apply for routes receives from other BGP speakers in the same autonomous system. To avoid long-lived black holes, the procedure does not apply to the explicit withdrawal of unfeasible routes (that is, routes whose destinations (expressed as IP prefixes) are listed in the WITHDRAWN ROUTES field of an UPDATE message).
速い集合が自律システムの中で必要であるときに、ルートが同じ自律システムの他のBGPスピーカーから受信されるので、この手順は適用されません。 長命のブラックホールを避けるために、手順は実行不可能なルート(すなわち、目的地(IP接頭語として、言い表される)がUPDATEメッセージのWITHDRAWN ROUTES分野に記載されているルート)の明白な退出に適用されません。
This procedure does not limit the rate of route selection, but only the rate of route advertisement. If new routes are selected multiple times while awaiting the expiration of MinRouteAdvertisementInterval, the last route selected shall be advertised at the end of MinRouteAdvertisementInterval.
この手順はルート選択の速度を制限するのではなく、ルート広告の速度だけを制限します。 MinRouteAdvertisementIntervalの満了を待っている間、複数の回新しいルートを選択するなら、MinRouteAdvertisementIntervalの端に選択された最後のルートの広告を出すものとします。
9.2.3.2 Frequency of Route Origination
9.2.3.2 ルート創作の頻度
The parameter MinASOriginationInterval determines the minimum amount of time that must elapse between successive advertisements of UPDATE messages that report changes within the advertising BGP speaker's own autonomous systems.
パラメタMinASOriginationIntervalは広告BGPスピーカーの自己の自律システムの中で変化を報告するUPDATEメッセージの連続した広告の間で経過しなければならない最小の時間を決定します。
Rekhter & Li [Page 43] RFC 1771 BGP-4 March 1995
Rekhterと李[43ページ]RFC1771BGP-1995年3月4日
9.2.3.3 Jitter
9.2.3.3 ジター
To minimize the likelihood that the distribution of BGP messages by a given BGP speaker will contain peaks, jitter should be applied to the timers associated with MinASOriginationInterval, Keepalive, and MinRouteAdvertisementInterval. A given BGP speaker shall apply the same jitter to each of these quantities regardless of the destinations to which the updates are being sent; that is, jitter will not be applied on a "per peer" basis.
与えられたBGPスピーカーによるBGPメッセージの分配がピークを含むという見込みを最小にするために、ジターはMinASOriginationInterval、Keepalive、およびMinRouteAdvertisementIntervalに関連しているタイマに適用されるべきです。 与えられたBGPスピーカーはアップデートが送られる目的地にかかわらずそれぞれのこれらの量に同じジターを適用するものとします。 すなわち、ジターは「同輩」ベースで適用されないでしょう。
The amount of jitter to be introduced shall be determined by multiplying the base value of the appropriate timer by a random factor which is uniformly distributed in the range from 0.75 to 1.0.
導入されるべきジターの量は、適切なタイマの基礎点を偶然要因に掛けることによって、測定されるものとします(0.75〜1.0までの範囲で一様に分配されます)。
9.2.4 Efficient Organization of Routing Information
9.2.4 経路情報の効率的な組織
Having selected the routing information which it will advertise, a BGP speaker may avail itself of several methods to organize this information in an efficient manner.
それが広告を出すルーティング情報を選択したので、BGPスピーカーは効率的な方法でこの情報を組織化するいくつかの方法をそれ自体に利用するかもしれません。
9.2.4.1 Information Reduction
9.2.4.1 情報減少
Information reduction may imply a reduction in granularity of policy control - after information is collapsed, the same policies will apply to all destinations and paths in the equivalence class.
情報減少は方針コントロールの粒状の減少を含意するかもしれません--情報が潰された後に、同じ方針は同値類ですべての目的地と経路に適用されるでしょう。
The Decision Process may optionally reduce the amount of information that it will place in the Adj-RIBs-Out by any of the following methods:
Decision Processは外のAdj-RIBsで以下の方法のどれかで入賞するという情報の量を任意に減少させるかもしれません:
a) Network Layer Reachability Information (NLRI):
a) ネットワーク層可到達性情報(NLRI):
Destination IP addresses can be represented as IP address
prefixes. In cases where there is a correspondence between the
address structure and the systems under control of an autonomous
system administrator, it will be possible to reduce the size of
the NLRI carried in the UPDATE messages.
IPアドレス接頭語として送付先IPアドレスを表すことができます。 自律システム管理者で制御されたアドレス構造とシステムとの通信がある場合では、UPDATEメッセージで運ばれたNLRIのサイズを減少させるのは可能でしょう。
b) AS_PATHs:
b) _経路として:
AS path information can be represented as ordered AS_SEQUENCEs or
unordered AS_SETs. AS_SETs are used in the route aggregation
algorithm described in 9.2.4.2. They reduce the size of the
AS_PATH information by listing each AS number only once,
regardless of how many times it may have appeared in multiple
AS_PATHs that were aggregated.
AS_SEQUENCEsか順不同のAS_SETsを注文するので、AS経路情報を表すことができます。 使用されるAS_SETsは9.2で.2にルート集合アルゴリズムで.4について説明しました。 彼らは一度だけそれぞれのAS番号を記載することによって、AS_PATH情報のサイズを減少させます、何回複数のAS_PATHsでそれが集められたように見えたかもしれないかにかかわらず。
Rekhter & Li [Page 44] RFC 1771 BGP-4 March 1995
Rekhterと李[44ページ]RFC1771BGP-1995年3月4日
An AS_SET implies that the destinations listed in the NLRI can be
reached through paths that traverse at least some of the
constituent autonomous systems. AS_SETs provide sufficient
information to avoid routing information looping; however their
use may prune potentially feasible paths, since such paths are no
longer listed individually as in the form of AS_SEQUENCEs. In
practice this is not likely to be a problem, since once an IP
packet arrives at the edge of a group of autonomous systems, the
BGP speaker at that point is likely to have more detailed path
information and can distinguish individual paths to destinations.
AS_SETは、NLRIに記載された目的地に少なくともいくつかの構成している自律システムを横断する経路を通して達することができるのを含意します。AS_SETsは情報ループを発送するのを避けるために十分な情報を前提とします。 しかしながら、彼らの使用は潜在的に可能な経路を剪定するかもしれません、そのような経路がもうAS_SEQUENCEsの形のように個別に記載されていないので。 実際には、これは問題である傾向がありません、IPパケットがいったん自律システムのグループの縁に到着すると、BGPスピーカーがその時、より詳細な経路情報を持ちそうであって、個々の経路を目的地に区別できるので。
9.2.4.2 Aggregating Routing Information
9.2.4.2 経路情報に集めること。
Aggregation is the process of combining the characteristics of several different routes in such a way that a single route can be advertised. Aggregation can occur as part of the decision process to reduce the amount of routing information that will be placed in the Adj-RIBs-Out.
集合はただ一つのルートの広告を出すことができるような方法における、数個の異なったルートの特性を結合する過程です。 集合は、外のAdj-RIBsに置かれるルーティング情報の量を減少させるために決定の過程の一部として起こることができます。
Aggregation reduces the amount of information that a BGP speaker must store and exchange with other BGP speakers. Routes can be aggregated by applying the following procedure separately to path attributes of like type and to the Network Layer Reachability Information.
集合は他のBGPスピーカーと共にBGPスピーカーが格納しなければならない情報と交換の量を減少させます。 別々に同様のタイプの経路属性と、そして、Network Layer Reachability情報に以下の手順を適用することによって、ルートを集めることができます。
Routes that have the following attributes shall not be aggregated unless the corresponding attributes of each route are identical: MULTI_EXIT_DISC, NEXT_HOP.
それぞれのルートの対応する属性が同じでない場合、以下の属性を持っているルートを集めないものとします: マルチ_は_ディスク、次の_ホップを出ます。
Path attributes that have different type codes can not be aggregated together. Path of the same type code may be aggregated, according to the following rules:
異なったタイプコードを持っている経路属性は一緒に集めることができません。 以下の規則に従って、同じタイプコードの経路は集められるかもしれません:
ORIGIN attribute: If at least one route among routes that are
aggregated has ORIGIN with the value INCOMPLETE, then the
aggregated route must have the ORIGIN attribute with the value
INCOMPLETE. Otherwise, if at least one route among routes that are
aggregated has ORIGIN with the value EGP, then the aggregated
route must have the origin attribute with the value EGP. In all
other case the value of the ORIGIN attribute of the aggregated
route is INTERNAL.
ORIGINは以下を結果と考えます。 集められるルートの中の少なくとも1つのルートに値のINCOMPLETEとORIGINがあるなら、集められたルートには、値のINCOMPLETEがあるORIGIN属性がなければなりません。 さもなければ、集められるルートの中の少なくとも1つのルートに値のEGPとORIGINがあるなら、集められたルートには値のEGPがある起源属性がなければなりません。 他のすべての場合では、集められたルートのORIGIN属性の値はINTERNALです。
AS_PATH attribute: If routes to be aggregated have identical
AS_PATH attributes, then the aggregated route has the same AS_PATH
attribute as each individual route.
AS_PATHは以下を結果と考えます。 集められるべきルートに同じAS_PATH属性があるなら、集められたルートには、それぞれの独特のルートと同じAS_PATH属性があります。
For the purpose of aggregating AS_PATH attributes we model each AS
within the AS_PATH attribute as a tuple <type, value>, where
"type" identifies a type of the path segment the AS belongs to
AS_PATH属性に集める目的のために、私たちはtuple<タイプとしてAS_PATH属性の中で各ASをモデル化します、値の>、「タイプ」がASが属す経路セグメントのタイプを特定するところで
Rekhter & Li [Page 45] RFC 1771 BGP-4 March 1995
Rekhterと李[45ページ]RFC1771BGP-1995年3月4日
(e.g. AS_SEQUENCE, AS_SET), and "value" is the AS number. If the
routes to be aggregated have different AS_PATH attributes, then
the aggregated AS_PATH attribute shall satisfy all of the
following conditions:
(例えば、AS_SEQUENCE、AS_SET)、「値」はAS番号です。 集められるべきルートに異なったAS_PATH属性があるなら、集められたAS_PATH属性は以下の条件のすべてを満たすものとします:
- all tuples of the type AS_SEQUENCE in the aggregated AS_PATH
shall appear in all of the AS_PATH in the initial set of routes
to be aggregated.
- 集められたAS_PATHのタイプAS_SEQUENCEのすべてのtuplesがAS_PATHのすべてに集められるべきルートの始発に現れるものとします。
- all tuples of the type AS_SET in the aggregated AS_PATH shall
appear in at least one of the AS_PATH in the initial set (they
may appear as either AS_SET or AS_SEQUENCE types).
- 集められたAS_PATHのタイプAS_SETのすべてのtuplesが少なくともAS_PATHの1つに始発に現れるものとします(AS_SETかAS_SEQUENCEのどちらかがタイプするように彼らは見えるかもしれません)。
- for any tuple X of the type AS_SEQUENCE in the aggregated
AS_PATH which precedes tuple Y in the aggregated AS_PATH, X
precedes Y in each AS_PATH in the initial set which contains Y,
regardless of the type of Y.
- 集められたAS_PATHでtuple Yに先行する集められたAS_PATHのタイプAS_SEQUENCEのどんなtuple Xに関してはも、XはYを含む始発における各AS_PATHでYに先行します、Yのタイプにかかわらず。
- No tuple with the same value shall appear more than once in
the aggregated AS_PATH, regardless of the tuple's type.
- 同じ値があるtupleは全く集められたAS_PATHで一度より多く見えないものとします、tupleのタイプにかかわらず。
An implementation may choose any algorithm which conforms to these
rules. At a minimum a conformant implementation shall be able to
perform the following algorithm that meets all of the above
conditions:
実現はこれらの規則に従うどんなアルゴリズムも選ぶかもしれません。 最小限では、conformant実現は上記の状態のすべてに会う以下のアルゴリズムを実行できるでしょう:
- determine the longest leading sequence of tuples (as defined
above) common to all the AS_PATH attributes of the routes to be
aggregated. Make this sequence the leading sequence of the
aggregated AS_PATH attribute.
- ルートのすべてのAS_PATH属性に共通のtuples(上で定義されるように)の最も長い主な系列が集められることを決定してください。 この系列を集められたAS_PATH属性の主な系列にしてください。
- set the type of the rest of the tuples from the AS_PATH
attributes of the routes to be aggregated to AS_SET, and append
them to the aggregated AS_PATH attribute.
- ルートのAS_PATH属性からのtuplesの残りのタイプにAS_SETに集められるように設定してください、そして、集められたAS_PATH属性に彼らを追加してください。
- if the aggregated AS_PATH has more than one tuple with the
same value (regardless of tuple's type), eliminate all, but one
such tuple by deleting tuples of the type AS_SET from the
aggregated AS_PATH attribute.
- 集められたAS_PATHに同じ値(tupleのタイプにかかわらず)がある1tupleがあるなら、集められたAS_PATH属性からタイプAS_SETのtuplesを削除することによって、そのようなtupleの1つ以外のすべてを排除してください。
Appendix 6, section 6.8 presents another algorithm that satisfies
the conditions and allows for more complex policy configurations.
付録6、セクション6.8は条件を満たして、より複雑な方針構成を考慮する別のアルゴリズムを提示します。
ATOMIC_AGGREGATE: If at least one of the routes to be aggregated
has ATOMIC_AGGREGATE path attribute, then the aggregated route
shall have this attribute as well.
原子_集合: 少なくとも集められるべきルートの1つにATOMIC_AGGREGATE経路属性があるなら、集められたルートには、また、この属性があるものとします。
Rekhter & Li [Page 46] RFC 1771 BGP-4 March 1995
Rekhterと李[46ページ]RFC1771BGP-1995年3月4日
AGGREGATOR: All AGGREGATOR attributes of all routes to be
aggregated should be ignored.
アグリゲータ: すべてのAGGREGATOR属性が集められるために発送するすべてが無視されるべきです。
9.3 Route Selection Criteria
9.3 ルート選択評価基準
Generally speaking, additional rules for comparing routes among several alternatives are outside the scope of this document. There are two exceptions:
概して、このドキュメントの範囲の外にいくつかの選択肢の中でルートを比較するための付則があります。 2つの例外があります:
- If the local AS appears in the AS path of the new route being
considered, then that new route cannot be viewed as better than
any other route. If such a route were ever used, a routing loop
would result.
- 考えられて、地方のASが新しいルートのAS経路に現れるなら、いかなる他のルートよりも良いとしてその新しいルートを見なすことができません。 そのようなルートが今までに使用されたなら、ルーティング輪は結果として生じるでしょう。
- In order to achieve successful distributed operation, only
routes with a likelihood of stability can be chosen. Thus, an AS
must avoid using unstable routes, and it must not make rapid
spontaneous changes to its choice of route. Quantifying the terms
"unstable" and "rapid" in the previous sentence will require
experience, but the principle is clear.
- うまくいっている分配された操作を達成するために、安定性の見込みがあるルートしか選ぶことができません。 したがって、ASは、不安定なルートを使用するのを避けなければなりません、そして、それはルートの選択への急速な自発変化を作ってはいけません。 前の文で「不安定で」「急速な」用語を定量化するのは経験を必要とするでしょうが、原則は明確です。
9.4 Originating BGP routes
9.4 由来しているBGPルート
A BGP speaker may originate BGP routes by injecting routing information acquired by some other means (e.g. via an IGP) into BGP. A BGP speaker that originates BGP routes shall assign the degree of preference to these routes by passing them through the Decision Process (see Section 9.1). These routes may also be distributed to other BGP speakers within the local AS as part of the Internal update process (see Section 9.2.1). The decision whether to distribute non- BGP acquired routes within an AS via BGP or not depends on the environment within the AS (e.g. type of IGP) and should be controlled via configuration.
BGPスピーカーは、ある他の手段(例えば、IGPを通した)で取得されたルーティング情報をBGPに注入することによって、BGPルートを溯源するかもしれません。 BGPルートを溯源するBGPスピーカーは、Decision Processにそれらを通すことによって、好みの度合いをこれらのルートに割り当てるものとします(セクション9.1を見てください)。 また、これらのルートはInternal更新処理の一部として地方のASの中の他のBGPスピーカーに分配されるかもしれません(セクション9.2.1を見てください)。 非BGPを分配するかどうかという決定は、BGPを通してASの中でルートを入手するべきであるか、AS(例えば、IGPのタイプ)の中で環境に依存しないで、または構成で制御されるべきです。
Rekhter & Li [Page 47] RFC 1771 BGP-4 March 1995
Rekhterと李[47ページ]RFC1771BGP-1995年3月4日
Appendix 1. BGP FSM State Transitions and Actions.
付録1。 BGP FSMは変遷と動作を述べます。
This Appendix discusses the transitions between states in the BGP FSM in response to BGP events. The following is the list of these states and events when the negotiated Hold Time value is non-zero.
このAppendixはBGP出来事に対応してBGP FSMの州の間の変遷について議論します。 交渉されたHold Time値が非ゼロであるときに、↓これはこれらの州と出来事のリストです。
BGP States:
BGP州:
1 - Idle
2 - Connect
3 - Active
4 - OpenSent
5 - OpenConfirm
6 - Established
1(活動していない2)はOpenSent5(OpenConfirm6)が確立した3(アクティブな4)を接続します。
BGP Events:
BGP出来事:
1 - BGP Start
2 - BGP Stop
3 - BGP Transport connection open
4 - BGP Transport connection closed
5 - BGP Transport connection open failed
6 - BGP Transport fatal error
7 - ConnectRetry timer expired
8 - Hold Timer expired
9 - KeepAlive timer expired
10 - Receive OPEN message
11 - Receive KEEPALIVE message
12 - Receive UPDATE messages
13 - Receive NOTIFICATION message
1--BGP Start2--BGP Transport接続は5を閉じました--BGP Transport接続戸外が6--BGP Transportの致命的な誤り7--ConnectRetryタイマ満期の8に失敗したというBGP Transport接続開いている4はTimerの満期の9を保持します--KeepAliveタイマが10を吐き出したというBGP Stop3はオープンメッセージ11を受け取ります--KEEPALIVEメッセージ12を受け取ってください--UPDATEメッセージ13を受け取ってください--NOTIFICATIONメッセージを受け取ってください。
Rekhter & Li [Page 48] RFC 1771 BGP-4 March 1995
Rekhterと李[48ページ]RFC1771BGP-1995年3月4日
The following table describes the state transitions of the BGP FSM and the actions triggered by these transitions.
以下のテーブルはBGP FSMの状態遷移とこれらの変遷で引き起こされた動作について説明します。
Event Actions Message Sent Next State
--------------------------------------------------------------------
Idle (1)
1 Initialize resources none 2
Start ConnectRetry timer
Initiate a transport connection
others none none 1
次の状態に送られたイベント動作メッセージ-------------------------------------------------------------------- なにもに(1) 1Initializeのリソースを空費してください、2、Start ConnectRetryタイマInitiate aがなにもになにもに接続他のものを輸送する、1
Connect(2)
1 none none 2
3 Complete initialization OPEN 4
Clear ConnectRetry timer
5 Restart ConnectRetry timer none 3
7 Restart ConnectRetry timer none 2
Initiate a transport connection
others Release resources none 1
なにもになにもに(2)1を接続してください、2 3Complete初期化オープン4Clear ConnectRetryタイマ5Restart ConnectRetryタイマ、なにも、3 7Restart ConnectRetryタイマ、なにも、2、Initiate aがなにもに接続他のものReleaseリソースを輸送する、1
Active (3)
1 none none 3
3 Complete initialization OPEN 4
Clear ConnectRetry timer
5 Close connection 3
Restart ConnectRetry timer
7 Restart ConnectRetry timer none 2
Initiate a transport connection
others Release resources none 1
アクティブな(3)1、なにも、なにも、3 3Complete初期化オープン4Clear ConnectRetryタイマ5Close接続3Restart ConnectRetryタイマ7Restart ConnectRetryタイマ、なにも、2、Initiate aがなにもに接続他のものReleaseリソースを輸送する、1
OpenSent(4)
1 none none 4
4 Close transport connection none 3
Restart ConnectRetry timer
6 Release resources none 1
10 Process OPEN is OK KEEPALIVE 5
Process OPEN failed NOTIFICATION 1
others Close transport connection NOTIFICATION 1
Release resources
OpenSent(4)1、なにも、なにも、4 4Closeが接続のためになにも輸送しない、3Restart ConnectRetryタイマ6Releaseリソース、なにも、1、10ProcessオープンはOK KEEPALIVE5Processオープンの失敗したNOTIFICATION1他のものClose輸送接続NOTIFICATION1Releaseリソースです。
Rekhter & Li [Page 49] RFC 1771 BGP-4 March 1995
Rekhterと李[49ページ]RFC1771BGP-1995年3月4日
OpenConfirm (5)
1 none none 5
4 Release resources none 1
6 Release resources none 1
9 Restart KeepAlive timer KEEPALIVE 5
11 Complete initialization none 6
Restart Hold Timer
13 Close transport connection 1
Release resources
others Close transport connection NOTIFICATION 1
Release resources
OpenConfirm(5)1、なにも、なにも、5 4のReleaseリソース、なにも、1 6のReleaseリソース、なにも、1 9Restart KeepAliveタイマKEEPALIVE、5、11Complete初期化、なにも、6Restart Hold Timer13Closeは接続1Releaseリソース他のもののためにClose輸送接続NOTIFICATION1Releaseリソースを輸送します。
Established (6)
1 none none 6
4 Release resources none 1
6 Release resources none 1
9 Restart KeepAlive timer KEEPALIVE 6
11 Restart Hold Timer KEEPALIVE 6
12 Process UPDATE is OK UPDATE 6
Process UPDATE failed NOTIFICATION 1
13 Close transport connection 1
Release resources
others Close transport connection NOTIFICATION 1
Release resources
---------------------------------------------------------------------
(6) 1がなにもになにもに設立した、6 4のReleaseリソース、なにも、1 6のReleaseリソース、なにも、1 9Restart KeepAliveタイマKEEPALIVE6 11Restart Hold Timer KEEPALIVE、6、12Process UPDATE、OK UPDATE6Process UPDATEがNOTIFICATION1 13Close輸送接続1Releaseリソース他のもののためにClose輸送接続NOTIFICATION1Releaseリソースに失敗したということです。---------------------------------------------------------------------
Rekhter & Li [Page 50] RFC 1771 BGP-4 March 1995
Rekhterと李[50ページ]RFC1771BGP-1995年3月4日
The following is a condensed version of the above state transition
table.
↓これは上の状態遷移テーブルの縮約版です。
Events| Idle | Connect | Active | OpenSent | OpenConfirm | Estab
| (1) | (2) | (3) | (4) | (5) | (6)
|--------------------------------------------------------------
1 | 2 | 2 | 3 | 4 | 5 | 6
| | | | | |
2 | 1 | 1 | 1 | 1 | 1 | 1
| | | | | |
3 | 1 | 4 | 4 | 1 | 1 | 1
| | | | | |
4 | 1 | 1 | 1 | 3 | 1 | 1
| | | | | |
5 | 1 | 3 | 3 | 1 | 1 | 1
| | | | | |
6 | 1 | 1 | 1 | 1 | 1 | 1
| | | | | |
7 | 1 | 2 | 2 | 1 | 1 | 1
| | | | | |
8 | 1 | 1 | 1 | 1 | 1 | 1
| | | | | |
9 | 1 | 1 | 1 | 1 | 5 | 6
| | | | | |
10 | 1 | 1 | 1 | 1 or 5 | 1 | 1
| | | | | |
11 | 1 | 1 | 1 | 1 | 6 | 6
| | | | | |
12 | 1 | 1 | 1 | 1 | 1 | 1 or 6
| | | | | |
13 | 1 | 1 | 1 | 1 | 1 | 1
| | | | | |
---------------------------------------------------------------
出来事| 怠けてください。| 接続してください。| アクティブ| OpenSent| OpenConfirm| Estab| (1) | (2) | (3) | (4) | (5) | (6) |-------------------------------------------------------------- 1 | 2 | 2 | 3 | 4 | 5 | 6 | | | | | | 2 | 1 | 1 | 1 | 1 | 1 | 1 | | | | | | 3 | 1 | 4 | 4 | 1 | 1 | 1 | | | | | | 4 | 1 | 1 | 1 | 3 | 1 | 1 | | | | | | 5 | 1 | 3 | 3 | 1 | 1 | 1 | | | | | | 6 | 1 | 1 | 1 | 1 | 1 | 1 | | | | | | 7 | 1 | 2 | 2 | 1 | 1 | 1 | | | | | | 8 | 1 | 1 | 1 | 1 | 1 | 1 | | | | | | 9 | 1 | 1 | 1 | 1 | 5 | 6 | | | | | | 10 | 1 | 1 | 1 | 1か5| 1 | 1 | | | | | | 11 | 1 | 1 | 1 | 1 | 6 | 6 | | | | | | 12 | 1 | 1 | 1 | 1 | 1 | 1か6| | | | | | 13 | 1 | 1 | 1 | 1 | 1 | 1 | | | | | | ---------------------------------------------------------------
Appendix 2. Comparison with RFC1267
付録2。 RFC1267との比較
BGP-4 is capable of operating in an environment where a set of reachable destinations may be expressed via a single IP prefix. The concept of network classes, or subnetting is foreign to BGP-4. To accommodate these capabilities BGP-4 changes semantics and encoding associated with the AS_PATH attribute. New text has been added to define semantics associated with IP prefixes. These abilities allow BGP-4 to support the proposed supernetting scheme [9].
BGP-4は1セットの届いている目的地がただ一つのIP接頭語で言い表されるかもしれないところで環境で作動できます。 ネットワークの概念が属するか、またはサブネッティングはBGP-4に外国です。 これらの能力BGP-4変化を収容するために、意味論とコード化はAS_PATH属性と交際しました。 新しいテキストは、IP接頭語に関連している意味論を定義するために加えられます。 これらの能力で、BGP-4は提案されたスーパーネッティング計画[9]を支持できます。
To simplify configuration this version introduces a new attribute, LOCAL_PREF, that facilitates route selection procedures.
構成を簡素化するために、このバージョンは新しい属性、ルート選択手順を容易にするLOCAL_PREFを導入します。
Rekhter & Li [Page 51] RFC 1771 BGP-4 March 1995
Rekhterと李[51ページ]RFC1771BGP-1995年3月4日
The INTER_AS_METRIC attribute has been renamed to be MULTI_EXIT_DISC. A new attribute, ATOMIC_AGGREGATE, has been introduced to insure that certain aggregates are not de-aggregated. Another new attribute, AGGREGATOR, can be added to aggregate routes in order to advertise which AS and which BGP speaker within that AS caused the aggregation.
INTER_AS_METRIC属性は、MULTI_EXIT_DISCになるように改名されました。 ある集合が反-集められないのを保障するために、新しい属性(ATOMIC_AGGREGATE)を導入しました。 集合が引き起こされたそのASの中にどのASとどのBGPスピーカーの広告を出すかためにルートに集めるために、別の新しい属性(AGGREGATOR)を加えることができます。
To insure that Hold Timers are symmetric, the Hold Time is now negotiated on a per-connection basis. Hold Times of zero are now supported.
Hold Timersが左右対称であることを保障するために、Hold Timeは現在、1接続あたり1個のベースに関して交渉されます。 ゼロ保持タイムズが現在、サポートされます。
Appendix 3. Comparison with RFC 1163
付録3。 RFC1163との比較
All of the changes listed in Appendix 2, plus the following.
変化のすべてがAppendix2、および以下に記載しました。
To detect and recover from BGP connection collision, a new field (BGP Identifier) has been added to the OPEN message. New text (Section 6.8) has been added to specify the procedure for detecting and recovering from collision.
BGP接続衝突から検出して、回復するために、新しい分野(BGP Identifier)をオープンメッセージに追加してあります。 新しいテキスト(セクション6.8)は、衝突から検出して、回復するための手順を指定するために加えられます。
The new document no longer restricts the border router that is passed in the NEXT_HOP path attribute to be part of the same Autonomous System as the BGP Speaker.
新しいドキュメントはもうBGP議長と同じAutonomous Systemの一部になるようにネクスト_HOP経路属性で通過される境界ルータを制限しません。
New document optimizes and simplifies the exchange of the information about previously reachable routes.
新しいドキュメントは、以前に届いているルートの情報の交換を最適化して、簡素化します。
Appendix 4. Comparison with RFC 1105
付録4。 RFC1105との比較
All of the changes listed in Appendices 2 and 3, plus the following.
変化のすべてがAppendices2と3、および以下に記載しました。
Minor changes to the RFC1105 Finite State Machine were necessary to accommodate the TCP user interface provided by 4.3 BSD.
RFC1105 Finite州Machineへのマイナーチェンジが、4.3BSDによって提供されたTCPユーザーインタフェースを収容するのに必要でした。
The notion of Up/Down/Horizontal relations present in RFC1105 has been removed from the protocol.
プロトコルからRFC1105の現在の下がっているかUp/水平な関係の概念を取り除きました。
The changes in the message format from RFC1105 are as follows:
RFC1105からのメッセージ・フォーマットにおける変化は以下の通りです:
1. The Hold Time field has been removed from the BGP header and
added to the OPEN message.
1. Hold Time野原は、BGPヘッダーから移されて、オープンメッセージに追加されました。
2. The version field has been removed from the BGP header and
added to the OPEN message.
2. バージョン野原は、BGPヘッダーから移されて、オープンメッセージに追加されました。
3. The Link Type field has been removed from the OPEN message.
3. オープンメッセージからLink Type野原を取り除きました。
4. The OPEN CONFIRM message has been eliminated and replaced with
implicit confirmation provided by the KEEPALIVE message.
4. OPEN CONFIRMメッセージをKEEPALIVEメッセージで提供する暗黙の確認に排除して、取り替えました。
Rekhter & Li [Page 52] RFC 1771 BGP-4 March 1995
Rekhterと李[52ページ]RFC1771BGP-1995年3月4日
5. The format of the UPDATE message has been changed
significantly. New fields were added to the UPDATE message to
support multiple path attributes.
5. UPDATEメッセージの形式をかなり変えました。 新しい分野は複数の経路が属性であるとサポートするUPDATEメッセージに追加されました。
6. The Marker field has been expanded and its role broadened to
support authentication.
6. Marker分野を広げてあります、そして、役割は、認証をサポートするために広くなりました。
Note that quite often BGP, as specified in RFC 1105, is referred
to as BGP-1, BGP, as specified in RFC 1163, is referred to as
BGP-2, BGP, as specified in RFC1267 is referred to as BGP-3, and
BGP, as specified in this document is referred to as BGP-4.
BGP-2、RFC1267の指定されるとしてのBGPがこのドキュメントの指定されるとしてのBGP-3、およびBGPとBGP-4と呼ばれた状態で呼ばれるようにかなりしばしばRFC1105で指定されるBGPがBGP-1と呼ばれて、RFC1163で指定されるBGPが呼ばれることに注意してください。
Appendix 5. TCP options that may be used with BGP
付録5。 BGPと共に使用されるかもしれないTCPオプション
If a local system TCP user interface supports TCP PUSH function, then each BGP message should be transmitted with PUSH flag set. Setting PUSH flag forces BGP messages to be transmitted promptly to the receiver.
ローカルシステムTCPユーザーインタフェースが、TCP PUSHが機能であるとサポートするなら、それぞれのBGPメッセージはPUSH旗のセットで送られるべきです。 PUSHが旗を揚げさせる設定は即座に受信機に伝えられるべきBGPメッセージを強制します。
If a local system TCP user interface supports setting precedence for TCP connection, then the BGP transport connection should be opened with precedence set to Internetwork Control (110) value (see also [6]).
ローカルシステムTCPユーザーインタフェースが、TCP接続のために設定が先行であるとサポートするなら、BGP輸送接続はInternetwork Control(110)値に設定された先行で開かれるべきです。(また、[6])を見てください。
Appendix 6. Implementation Recommendations
付録6。 実装推薦
This section presents some implementation recommendations.
このセクションはいくつかの実装推薦を提示します。
6.1 Multiple Networks Per Message
6.1 複数の1メッセージあたりのネットワーク
The BGP protocol allows for multiple address prefixes 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 address prefix 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 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 address prefixes 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 address prefix is processed, a message for the associated AS path and gateway is allocated, if it does not exist, and the new address prefix is added to it. If such a message exists, the new address prefix is just appended to it. If the message lacks the space to hold the new address prefix, it is transmitted, a new message is allocated, and the new address prefix is inserted into the new message. When the entire routing table has been scanned, all
BGPプロトコルは、同じAS経路と次のホップゲートウェイがある複数のアドレス接頭語が1つのメッセージで指定されるのを許容します。 この能力を利用するのは非常にお勧めです。 1メッセージあたり1つのアドレス接頭語と共に、オーバーヘッドのかなりの増加が受信機にあります。また、システムオーバーヘッドが複数のメッセージのレセプションのため上がるだけではなく、BGP同輩へのアップデートと他のルーティング・プロトコル(関連メッセージを送って)のために経路指定テーブルをスキャンするオーバーヘッドは複数の回被られます。 AS経路単位で組織化されない経路指定テーブルから多くのAS経路あたりのアドレス接頭語とゲートウェイを含むメッセージを築き上げる1つのメソッドは経路指定テーブルがスキャンされるとき多くのメッセージを築き上げることです。 それぞれのアドレス接頭語を処理するとき、関連AS経路とゲートウェイへのメッセージを割り当てます、存在していなくて、新しいアドレス接頭語がそれに加えられるなら。 そのようなメッセージが存在しているなら、ただ新しいアドレス接頭語をそれに追加します。 メッセージが新しいアドレス接頭語を保持するスペースを欠いているなら、それを伝えます、そして、新しいメッセージを割り当てます、そして、新しいアドレス接頭語を新しいメッセージに挿入します。 全体の経路指定テーブルがスキャンされたときすべて
Rekhter & Li [Page 53] RFC 1771 BGP-4 March 1995
Rekhterと李[53ページ]RFC1771BGP-1995年3月4日
allocated messages are sent and their resources released. Maximum compression is achieved when all the destinations covered by the address prefixes share a gateway and common path attributes, making it possible to send many address prefixes in one 4096-byte message.
割り当てられたメッセージは、送って発表されたそれらのリソースです。 アドレス接頭語でカバーされたすべての目的地がゲートウェイと共通路属性を共有するとき、最大の圧縮は達成されます、1つの4096年のバイトのメッセージの多くのアドレス接頭語を送るのを可能にして。
When peering with a BGP implementation that does not compress multiple address prefixes 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 limit the rate of updates. This will eliminate 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. A better method would be to read all received messages before sending updates.
複数のアドレス接頭語を1つのメッセージに圧縮しないBGP実装でじっと見るとき、同輩が後天的であるか、または重要なネットワーク形態変化が起こるとき受け取られた膨大なデータからオーバーヘッドを下げるために手を打つのが必要であるかもしれません。 これをする1つのメソッドはアップデートの速度を制限することです。 これは、BGP同輩のためのフラッシュ最新版と他のルーティング・プロトコルを提供するために経路指定テーブルの余分なスキャンを排除するでしょう。 このアプローチの不都合はルーティング情報の伝播潜在を増強するということです。 わざわざそれが複数のメッセージを処理するあまり長くない最小のフラッシュアップデート間隔を選ぶことによって、この潜在は最小にされるべきです。 より良いメソッドはアップデートを送る前にすべての受信されたメッセージを読むだろうことです。
6.2 Processing Messages on a Stream Protocol
6.2 ストリームプロトコルに関する処理メッセージ
BGP uses TCP as a transport mechanism. Due to the stream nature of TCP, all the data for received messages does not necessarily arrive at the same time. 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.
BGPは移送機構としてTCPを使用します。 TCPのストリーム自然のため、受信されたメッセージのためのすべてのデータが同時に、必ず到着するというわけではありません。 これで、メッセージとしてデータを処理するのは難しくなる場合があります、どのくらいのデータを受け取りますが、まだ処理していないかを決定するのが可能でないBSD Unixなどのシステムの特に上で。
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 (4096 bytes) per peer and fill it with data as available until a complete message has been received.
この状況で使用できる1つのメソッドは最初にまさしくメッセージヘッダーを読もうとすることです。 KEEPALIVEメッセージタイプにおいて、これは完全なメッセージです。 他のメッセージタイプにおいて、ヘッダーは最初に、特に確かめられるべきです。全長。 すべてのチェックがうまくいくなら、ヘッダーが読むのを残っているデータ量であるというメッセージのサイズを引いて、指定された長さです。 同輩から読もうとしている間にルーティング情報プロセスを「掛かる」実装は、完全なメッセージを受け取るまで同輩単位でメッセージ・バッファ(4096バイト)をセットアップして、利用可能であるとしてデータでそれを満たすかもしれません。
6.3 Reducing route flapping
6.3 ルートのばたつくことを減少させること。
To avoid excessive route flapping a BGP speaker which needs to withdraw a destination and send an update about a more specific or less specific route shall combine them into the same UPDATE message.
BGPスピーカーをばたつかせる過度のルートを避けるために、どれが、より特定の、または、それほど特定でないルートに関して目的地を引き下がらせて、アップデートを送る必要があるかが同じUPDATEメッセージにそれらを結合するものとします。
Rekhter & Li [Page 54] RFC 1771 BGP-4 March 1995
Rekhterと李[54ページ]RFC1771BGP-1995年3月4日
6.4 BGP Timers
6.4 BGPタイマ
BGP employs five timers: ConnectRetry, Hold Time, KeepAlive, MinASOriginationInterval, and MinRouteAdvertisementInterval The suggested value for the ConnectRetry timer is 120 seconds. The suggested value for the Hold Time is 90 seconds. The suggested value for the KeepAlive timer is 30 seconds. The suggested value for the MinASOriginationInterval is 15 seconds. The suggested value for the MinRouteAdvertisementInterval is 30 seconds.
BGPは5個のタイマを使います: ConnectRetry、Hold Time、KeepAlive、MinASOriginationInterval、およびMinRouteAdvertisementInterval、ConnectRetryタイマのための提案された値は120秒です。 Hold Timeのための提案された値は90秒です。 KeepAliveタイマのための提案された値は30秒です。 MinASOriginationIntervalのための提案された値は15秒です。 MinRouteAdvertisementIntervalのための提案された値は30秒です。
An implementation of BGP MUST allow these timers to be configurable.
BGP MUSTの実装は、これらのタイマが構成可能であることを許容します。
6.5 Path attribute ordering
6.5 経路属性注文
Implementations which combine update messages as described above in
6.1 may prefer to see all path attributes presented in a known order.
This permits them to quickly identify sets of attributes from
different update messages which are semantically identical. To
facilitate this, it is a useful optimization to order the path
attributes according to type code. This optimization is entirely
optional.
上で6.1で説明されるようにアップデートメッセージを結合する実装は、すべての経路属性が知られているオーダーに示されるのを見るのを好むかもしれません。 これは、彼らが意味的に同じ異なったアップデートメッセージから属性のセットをすぐに特定することを許可します。 これを容易にするために、タイプコードによると、経路属性を命令するのは、役に立つ最適化です。 この最適化は完全に任意です。
6.6 AS_SET sorting
6.6 AS_SETソーティング
Another useful optimization that can be done to simplify this situation is to sort the AS numbers found in an AS_SET. This optimization is entirely optional.
この状況を簡素化するためにできる別の役に立つ最適化はAS_SETで見つけられたAS番号を分類することです。 この最適化は完全に任意です。
6.7 Control over version negotiation
6.7 バージョン交渉のコントロール
Since BGP-4 is capable of carrying aggregated routes which cannot be properly represented in BGP-3, an implementation which supports BGP-4 and another BGP version should provide the capability to only speak BGP-4 on a per-peer basis.
BGP-4がBGP-3に適切に表すことができない集められたルートを運ぶことができるので、BGP-4をサポートする実装と別のBGPバージョンは1同輩あたり1個のベースでBGP-4を話すだけである能力を提供するべきです。
6.8 Complex AS_PATH aggregation
6.8 複雑なAS_PATH集合
An implementation which chooses to provide a path aggregation algorithm which retains significant amounts of path information may wish to use the following procedure:
かなりの量の経路情報を保有する経路集合アルゴリズムを提供するのを選ぶ実装は以下の手順を用いたがっているかもしれません:
For the purpose of aggregating AS_PATH attributes of two routes,
we model each AS as a tuple <type, value>, where "type" identifies
a type of the path segment the AS belongs to (e.g. AS_SEQUENCE,
AS_SET), and "value" is the AS number. Two ASs are said to be the
same if their corresponding <type, value> tuples are the same.
2つのルートのAS_PATH属性に集める目的のために、私たちはtuple<タイプとして各ASをモデル化します、値の>、「タイプ」が経路セグメントのタイプを特定するところでASが属す、(例えば、AS_SEQUENCE、AS_SET)、「値」はAS番号です。 2ASsが彼らの対応する<タイプであるなら同じであると言われて、値の>tuplesは同じです。
Rekhter & Li [Page 55] RFC 1771 BGP-4 March 1995
Rekhterと李[55ページ]RFC1771BGP-1995年3月4日
The algorithm to aggregate two AS_PATH attributes works as
follows:
2つのAS_PATH属性に集めるアルゴリズムは以下の通り利きます:
a) Identify the same ASs (as defined above) within each AS_PATH
attribute that are in the same relative order within both
AS_PATH attributes. Two ASs, X and Y, are said to be in the
same order if either:
a) それぞれのAS_PATH属性の中の両方のAS_PATH属性の中に同じ相対オーダにはあるのと同じASs(上で定義されるように)を特定してください。 2ASs(XとY)がどちらかなら同次にはあると言われます:
- X precedes Y in both AS_PATH attributes, or - Y precedes X
in both AS_PATH attributes.
- または、Xが両方のAS_PATH属性におけるYに先行する、--Yは両方のAS_PATH属性におけるXに先行します。
b) The aggregated AS_PATH attribute consists of ASs identified
in (a) in exactly the same order as they appear in the AS_PATH
attributes to be aggregated. If two consecutive ASs identified
in (a) do not immediately follow each other in both of the
AS_PATH attributes to be aggregated, then the intervening ASs
(ASs that are between the two consecutive ASs that are the
same) in both attributes are combined into an AS_SET path
segment that consists of the intervening ASs from both AS_PATH
attributes; this segment is then placed in between the two
consecutive ASs identified in (a) of the aggregated attribute.
If two consecutive ASs identified in (a) immediately follow
each other in one attribute, but do not follow in another, then
the intervening ASs of the latter are combined into an AS_SET
path segment; this segment is then placed in between the two
consecutive ASs identified in (a) of the aggregated attribute.
b) 彼らは、集められるべきAS_PATH属性でまさに同じオーダーにおける(a)で特定されているように見えますが、集められたAS_PATH属性はASsから成ります。 (a)で特定された2連続したASsがすぐに集められるためにAS_PATH属性の両方で互いに続かないなら、両方の属性における介入しているASs(2同じである連続したASsの間にあるASs)は両方のAS_PATH属性からの介入しているASsから成るAS_SET経路セグメントに結合されます。 そして、このセグメントは集められた属性の(a)で特定された2連続したASsの間に置かれます。 すぐに(a)で特定された2連続したASsが1つの属性で互いに続きますが、別のもので続かないなら、後者の介入しているASsはAS_SET経路セグメントに結合されます。 そして、このセグメントは集められた属性の(a)で特定された2連続したASsの間に置かれます。
If as a result of the above procedure a given AS number appears
more than once within the aggregated AS_PATH attribute, all, but
the last instance (rightmost occurrence) of that AS number should
be removed from the aggregated AS_PATH attribute.
与えられたAS番号が上の手順の結果、集められたAS_PATH属性の中で一度より多く見えるなら、集められたAS_PATH属性からそのAS番号の最終審(一番右の発生)以外のすべてを取り除くべきです。
References
参照
[1] Mills, D., "Exterior Gateway Protocol Formal Specification", RFC
904, BBN, April 1984.
[1] 工場、D.、「外のゲートウェイプロトコル形式仕様」、RFC904、BBN、1984年4月。
[2] Rekhter, Y., "EGP and Policy Based Routing in the New NSFNET
Backbone", RFC 1092, T.J. Watson Research Center, February 1989.
[2] Rekhter、Y.、「EGPと方針は新しいNSFNETバックボーンにおけるルート設定を基礎づけました」、RFC1092、T.J.ワトソン研究所、1989年2月。
[3] Braun, H-W., "The NSFNET Routing Architecture", RFC 1093,
MERIT/NSFNET Project, February 1989.
[3] ブラウン、H-W.、「NSFNETルート設定アーキテクチャ」、RFC1093、長所/NSFNETは1989年2月に突出します。
[4] Postel, J., "Transmission Control Protocol - DARPA Internet
Program Protocol Specification", STD 7, RFC 793, DARPA, September
1981.
[4] ポステル、J.、「転送管理は議定書を作ります--DARPAインターネットはプロトコル仕様をプログラムする」STD7、RFC793、DARPA、1981年9月。
Rekhter & Li [Page 56] RFC 1771 BGP-4 March 1995
Rekhterと李[56ページ]RFC1771BGP-1995年3月4日
[5] Rekhter, Y., and P. Gross, "Application of the Border Gateway
Protocol in the Internet", RFC 1772, T.J. Watson Research Center,
IBM Corp., MCI, March 1995.
Rekhter、Y.、およびP.が利益を上げる[5]、「インターネットでのボーダ・ゲイトウェイ・プロトコルの応用」、RFC1772、T.J.ワトソン研究所、IBM社、MCI(1995年3月)。
[6] Postel, J., "Internet Protocol - DARPA Internet Program Protocol
Specification", STD 5, RFC 791, DARPA, September 1981.
[6] ポステル、J.、「インターネットは議定書を作ります--DARPAインターネットはプロトコル仕様をプログラムする」STD5、RFC791、DARPA、1981年9月。
[7] "Information Processing Systems - Telecommunications and
Information Exchange between Systems - Protocol for Exchange of
Inter-domain Routeing Information among Intermediate Systems to
Support Forwarding of ISO 8473 PDUs", ISO/IEC IS10747, 1993
[7]、「情報処理システム(システムの間のテレコミュニケーションと情報交換)が相互ドメインRouteing情報の交換のために推進をサポートする中間システムの中で議定書を作る、ISO8473PDUs、」、ISO/IEC IS10747、1993
[8] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Classless Inter-
Domain Routing (CIDR): an Address Assignment and Aggregation
Strategy", RFC 1519, BARRNet, cisco, MERIT, OARnet, September
1993
[8] フラー、V.、李、T.、ユー、J.、およびK.Varadhan、「以下を掘る(CIDR)階級のない相互ドメイン」 「Address AssignmentとAggregation Strategy」、RFC1519、BARRNet、コクチマス、MERIT、OARnet、1993年9月
[9] Rekhter, Y., Li, T., "An Architecture for IP Address Allocation
with CIDR", RFC 1518, T.J. Watson Research Center, cisco,
September 1993
[9]Rekhter、Y.、李、T.、「CIDRとのIPアドレス配分のためのアーキテクチャ」、RFC1518、T.J.ワトソン研究所、コクチマス、1993年9月
Security Considerations
セキュリティ問題
Security issues are not discussed in this document.
本書では安全保障問題について議論しません。
Editors' 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
Tony Li cisco Systems, Inc. 170 W. Tasman Dr. San Jose, CA 95134
サンノゼ、トニー李コクチマスSystems Inc.170W.タスマン博士カリフォルニア 95134
EMail: tli@cisco.com
メール: tli@cisco.com
Rekhter & Li [Page 57]
Rekhterと李[57ページ]
一覧
スポンサーリンク
