RFC4271 日本語訳
4271 A Border Gateway Protocol 4 (BGP-4). Y. Rekhter, Ed., T. Li, Ed.,S. Hares, Ed.. January 2006. (Format: TXT=222702 bytes) (Obsoletes RFC1771) (Status: DRAFT STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group Y. Rekhter, Ed. Request for Comments: 4271 T. Li, Ed. Obsoletes: 1771 S. Hares, Ed. Category: Standards Track January 2006
ワーキンググループY.Rekhter、エドをネットワークでつないでください。コメントのために以下を要求してください。 4271 T.李、エド、時代遅れにします: 1771秒間エド野兎、カテゴリ: 標準化過程2006年1月
A Border Gateway Protocol 4 (BGP-4)
ボーダ・ゲイトウェイ・プロトコル4(BGP-4)
Status of This 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)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(2006)。
Abstract
要約
This document discusses the Border Gateway Protocol (BGP), which is an inter-Autonomous System routing protocol.
このドキュメントはボーダ・ゲイトウェイ・プロトコル(BGP)について議論します。(それは、相互Autonomous Systemルーティング・プロトコルです)。
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 (ASes) that reachability information traverses. This information is sufficient for constructing a graph of AS connectivity for this reachability from which routing loops may be pruned, and, at the AS level, some policy decisions may be enforced.
BGPがシステムを話すプライマリ機能は他のBGPシステムとネットワーク可到達性情報を交換することです。このネットワーク可到達性情報は可到達性情報が横断するAutonomous Systems(ASes)のリストの上の情報を含んでいます。 この情報はルーティング輪余計なものを取り除かれるかもしれないこの可到達性のためにASの接続性のグラフを作図するのに十分です、そして、ASレベルでは、いくつかの政策決定が励行されるかもしれません。
BGP-4 provides a set of mechanisms for supporting Classless Inter- Domain Routing (CIDR). These mechanisms include support for advertising a set of destinations as an IP prefix, and eliminating the concept of network "class" within BGP. BGP-4 also introduces mechanisms that allow aggregation of routes, including aggregation of AS paths.
Classless Interがドメインルート設定(CIDR)であるとサポートするのにBGP-4は1セットのメカニズムを提供します。 これらのメカニズムはIP接頭語として1セットの目的地の広告を出して、BGPの中でネットワーク「クラス」の概念を排除するサポートを含んでいます。 また、BGP-4はAS経路の集合を含むルートの集合を許容するメカニズムを紹介します。
This document obsoletes RFC 1771.
このドキュメントはRFC1771を時代遅れにします。
Rekhter, et al. Standards Track [Page 1] RFC 4271 BGP-4 January 2006
Rekhter、他 標準化過程[1ページ]RFC4271BGP-2006年1月4日
Table of Contents
目次
1. Introduction ....................................................4
1.1. Definition of Commonly Used Terms ..........................4
1.2. Specification of Requirements ..............................6
2. Acknowledgements ................................................6
3. Summary of Operation ............................................7
3.1. Routes: Advertisement and Storage ..........................9
3.2. Routing Information Base ..................................10
4. Message Formats ................................................11
4.1. Message Header Format .....................................12
4.2. OPEN Message Format .......................................13
4.3. UPDATE Message Format .....................................14
4.4. KEEPALIVE Message Format ..................................21
4.5. NOTIFICATION Message Format ...............................21
5. Path Attributes ................................................23
5.1. Path Attribute Usage ......................................25
5.1.1. ORIGIN .............................................25
5.1.2. AS_PATH ............................................25
5.1.3. NEXT_HOP ...........................................26
5.1.4. MULTI_EXIT_DISC ....................................28
5.1.5. LOCAL_PREF .........................................29
5.1.6. ATOMIC_AGGREGATE ...................................29
5.1.7. AGGREGATOR .........................................30
6. BGP Error Handling. ............................................30
6.1. Message Header Error Handling .............................31
6.2. OPEN Message Error Handling ...............................31
6.3. UPDATE Message Error Handling .............................32
6.4. NOTIFICATION Message Error Handling .......................34
6.5. Hold Timer Expired Error Handling .........................34
6.6. Finite State Machine Error Handling .......................35
6.7. Cease .....................................................35
6.8. BGP Connection Collision Detection ........................35
7. BGP Version Negotiation ........................................36
8. BGP Finite State Machine (FSM) .................................37
8.1. Events for the BGP FSM ....................................38
8.1.1. Optional Events Linked to Optional Session
Attributes .........................................38
8.1.2. Administrative Events ..............................42
8.1.3. Timer Events .......................................46
8.1.4. TCP Connection-Based Events ........................47
8.1.5. BGP Message-Based Events ...........................49
8.2. Description of FSM ........................................51
8.2.1. FSM Definition .....................................51
8.2.1.1. Terms "active" and "passive" ..............52
8.2.1.2. FSM and Collision Detection ...............52
8.2.1.3. FSM and Optional Session Attributes .......52
8.2.1.4. FSM Event Numbers .........................53
1. 序論…4 1.1. 一般的に使用された期間の定義…4 1.2. 要件の仕様…6 2. 承認…6 3. 操作の概要…7 3.1. ルート: 広告とストレージ…9 3.2. 経路情報基地…10 4. メッセージ形式…11 4.1. メッセージヘッダー形式…12 4.2. メッセージ・フォーマットを開いてください…13 4.3. メッセージ・フォーマットをアップデートしてください…14 4.4. KEEPALIVEメッセージ・フォーマット…21 4.5. 通知メッセージ形式…21 5. 経路属性…23 5.1. 経路属性用法…25 5.1.1. 発生源…25 5.1.2. _経路として…25 5.1.3. 次の_ホップ…26 5.1.4. マルチ_は_ディスクを出ます…28 5.1.5. 地方の_PREF…29 5.1.6. 原子_集合…29 5.1.7. アグリゲータ…30 6. BGPエラー処理。 ............................................30 6.1. メッセージヘッダーエラー処理…31 6.2. メッセージエラー処理を開いてください…31 6.3. メッセージエラー処理をアップデートしてください…32 6.4. 通知メッセージエラー処理…34 6.5. タイマの満期のエラー処理を保持してください…34 6.6. 有限状態機械エラー処理…35 6.7. やんでください…35 6.8. BGP接続衝突検出…35 7. BGPバージョン交渉…36 8. BGP有限状態機械(FSM)…37 8.1. BGP FSMのためのイベント…38 8.1.1. 任意のイベントは任意のセッション属性にリンクされました…38 8.1.2. 管理イベント…42 8.1.3. タイマイベント…46 8.1.4. TCPの接続ベースのイベント…47 8.1.5. BGPのメッセージベースのイベント…49 8.2. FSMの記述…51 8.2.1. FSM定義…51 8.2.1.1. 用語「アクティブで」「受動」…………。52 8.2.1.2. FSMと衝突検出…52 8.2.1.3. FSMと任意のセッション属性…52 8.2.1.4. FSMイベント番号…53
Rekhter, et al. Standards Track [Page 2] RFC 4271 BGP-4 January 2006
Rekhter、他 標準化過程[2ページ]RFC4271BGP-2006年1月4日
8.2.1.5. FSM Actions that are Implementation
Dependent .................................53
8.2.2. Finite State Machine ...............................53
9. UPDATE Message Handling ........................................75
9.1. Decision Process ..........................................76
9.1.1. Phase 1: Calculation of Degree of Preference .......77
9.1.2. Phase 2: Route Selection ...........................77
9.1.2.1. Route Resolvability Condition .............79
9.1.2.2. Breaking Ties (Phase 2) ...................80
9.1.3. Phase 3: Route Dissemination .......................82
9.1.4. Overlapping Routes .................................83
9.2. Update-Send Process .......................................84
9.2.1. Controlling Routing Traffic Overhead ...............85
9.2.1.1. Frequency of Route Advertisement ..........85
9.2.1.2. Frequency of Route Origination ............85
9.2.2. Efficient Organization of Routing Information ......86
9.2.2.1. Information Reduction .....................86
9.2.2.2. Aggregating Routing Information ...........87
9.3. Route Selection Criteria ..................................89
9.4. Originating BGP routes ....................................89
10. BGP Timers ....................................................90
Appendix A. Comparison with RFC 1771 .............................92
Appendix B. Comparison with RFC 1267 .............................93
Appendix C. Comparison with RFC 1163 .............................93
Appendix D. Comparison with RFC 1105 .............................94
Appendix E. TCP Options that May Be Used with BGP ................94
Appendix F. Implementation Recommendations .......................95
Appendix F.1. Multiple Networks Per Message .........95
Appendix F.2. Reducing Route Flapping ...............96
Appendix F.3. Path Attribute Ordering ...............96
Appendix F.4. AS_SET Sorting ........................96
Appendix F.5. Control Over Version Negotiation ......96
Appendix F.6. Complex AS_PATH Aggregation ...........96
Security Considerations ...........................................97
IANA Considerations ...............................................99
Normative References .............................................101
Informative References ...........................................101
8.2.1.5. Implementation DependentであるFSM Actions…53 8.2.2. 有限州のマシン…53 9. メッセージハンドリングをアップデートしてください…75 9.1. 決定プロセス…76 9.1.1. フェーズ1: 好みの度合いの計算…77 9.1.2. フェーズ2: 選択を発送してください…77 9.1.2.1. Resolvability状態を発送してください…79 9.1.2.2. 壊すのは(フェーズ2)を結びます…80 9.1.3. フェーズ3: 普及を発送してください…82 9.1.4. ルートを重ね合わせます…83 9.2. プロセスをアップデートして送ってください…84 9.2.1. ルート設定トラフィックオーバーヘッドを制御します…85 9.2.1.1. ルート広告の頻度…85 9.2.1.2. ルート創作の頻度…85 9.2.2. 経路情報の効率的な組織…86 9.2.2.1. 情報減少…86 9.2.2.2. 経路情報に集めます…87 9.3. 選択評価基準を発送してください…89 9.4. BGPルートを溯源します…89 10. BGPタイマ…90 RFC1771との付録A.比較…92 RFC1267との付録B.比較…93 RFC1163との付録C.比較…93 RFC1105との付録D.比較…94付録E.TCP Options、BGPとその5月のBe Used…94 付録F.実装推薦…95 付録F.1。 複数の1メッセージあたりのネットワーク…95 付録F.2。 ルートのばたつくことを減少させます…96 付録F.3。 経路属性注文…96 付録F.4。 _として、ソーティングを設定してください…96 付録F.5。 バージョン交渉の上で制御してください…96 付録F.6。 _経路集合としての複合体…96 セキュリティ問題…97 IANA問題…99 標準の参照…101 有益な参照…101
Rekhter, et al. Standards Track [Page 3] RFC 4271 BGP-4 January 2006
Rekhter、他 標準化過程[3ページ]RFC4271BGP-2006年1月4日
1. Introduction
1. 序論
The Border Gateway Protocol (BGP) is an inter-Autonomous System routing protocol.
ボーダ・ゲイトウェイ・プロトコル(BGP)は相互Autonomous Systemルーティング・プロトコルです。
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 (ASes) that reachability information traverses. This information is sufficient for constructing a graph of AS connectivity for this reachability, from which routing loops may be pruned and, at the AS level, some policy decisions may be enforced.
BGPがシステムを話すプライマリ機能は他のBGPシステムとネットワーク可到達性情報を交換することです。このネットワーク可到達性情報は可到達性情報が横断するAutonomous Systems(ASes)のリストの上の情報を含んでいます。 この情報はルーティング輪余計なものを取り除かれるかもしれないこの可到達性のためにASの接続性のグラフを作図するのに十分です、そして、ASレベルでは、いくつかの政策決定が励行されるかもしれません。
BGP-4 provides a set of mechanisms for supporting Classless Inter- Domain Routing (CIDR) [RFC1518, RFC1519]. These mechanisms include support for advertising a set of destinations as an IP prefix and eliminating the concept of network "class" within BGP. BGP-4 also introduces mechanisms that allow aggregation of routes, including aggregation of AS paths.
Classless Interがドメインルート設定(CIDR)[RFC1518、RFC1519]であるとサポートするのにBGP-4は1セットのメカニズムを提供します。 これらのメカニズムはIP接頭語として1セットの目的地の広告を出して、BGPの中でネットワーク「クラス」の概念を排除するサポートを含んでいます。 また、BGP-4はAS経路の集合を含むルートの集合を許容するメカニズムを紹介します。
Routing information exchanged via BGP supports only the destination- based forwarding paradigm, which assumes that a router forwards a packet based solely on the destination address carried in the IP header of the packet. This, in turn, reflects the set of policy decisions that can (and cannot) be enforced using BGP. BGP can support only those policies conforming to the destination-based forwarding paradigm.
BGPを通して交換されたルート設定情報は、唯一の目的地がベースの推進パラダイムであるとサポートします。(それは、ルータが唯一パケットのIPヘッダーで運ばれた送付先アドレスに基づくパケットを進めると仮定します)。 これは順番に缶の(and cannot)がBGPを使用することで実施されるという方針決定のセットを反映します。 BGPは目的地ベースの推進パラダイムに従うそれらの方針だけをサポートすることができます。
1.1. Definition of Commonly Used Terms
1.1. 一般的に使用された期間の定義
This section provides definitions for terms that have a specific meaning to the BGP protocol and that are used throughout the text.
このセクションはBGPプロトコルに特定の意味を持って、テキスト中で使用される用語に定義を提供します。
Adj-RIB-In
The Adj-RIBs-In contains unprocessed routing information that has
been advertised to the local BGP speaker by its peers.
中の中のAdj-RIB Adj-RIBsは同輩によって地元のBGPスピーカーに広告に掲載されている未加工のルーティング情報を含んでいます。
Adj-RIB-Out
The Adj-RIBs-Out contains the routes for advertisement to specific
peers by means of the local speaker's UPDATE messages.
外の外のAdj-RIB Adj-RIBsは地元のスピーカーのUPDATEメッセージによって特定の同輩に広告のためのルートを含んでいます。
Autonomous System (AS)
The classic definition of an Autonomous System is a set of routers
under a single technical administration, using an interior gateway
protocol (IGP) and common metrics to determine how to route
packets within the AS, and using an inter-AS routing protocol to
determine how to route packets to other ASes. Since this classic
definition was developed, it has become common for a single AS to
ASの中でどうパケットを発送するか、そして、相互ASルーティング・プロトコルを使用するのがその方法を決定するただ一つの技術的な管理の下における、1セットのルータであり、内部のゲートウェイを使用すると(IGP)と一般的な測定基準が議定書を作るAutonomous Systemの古典的な定義が、決定する自治のSystem(AS)は他のASesにパケットを発送します。 この古典的な定義が開発されて以来、それは独身のASに一般的になっています。
Rekhter, et al. Standards Track [Page 4] RFC 4271 BGP-4 January 2006
Rekhter、他 標準化過程[4ページ]RFC4271BGP-2006年1月4日
use several IGPs and, sometimes, several sets of metrics within an
AS. The use of the term Autonomous System stresses the fact that,
even when multiple IGPs and metrics are used, the administration
of an AS appears to other ASes to have a single coherent interior
routing plan, and presents a consistent picture of the
destinations that are reachable through it.
ASの中で数個のIGPsと時々数セットの測定基準を使用してください。 Autonomous Systemという用語の使用は、ただ一つの論理的な内部のルーティングプランを持つために、複数のIGPsと測定基準が使用されてさえいるとき、ASの管理が他のASesにおいて現れるという事実を強調して、それを通して届いている目的地の一貫した画像を提示します。
BGP Identifier
A 4-octet unsigned integer that indicates the BGP Identifier of
the sender of BGP messages. 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 upon startup and is
the same for every local interface and BGP peer.
BGP Identifier A、BGPメッセージの送付者のBGP Identifierを示す4八重奏の符号のない整数。 与えられたBGPスピーカーはそのBGPスピーカーに割り当てられたIPアドレスにBGP Identifierの値を設定します。 BGP Identifierの値は、始動のときに決定していて、すべての局所界面とBGP同輩にとって、同じです。
BGP speaker
A router that implements BGP.
BGPを実装するBGPスピーカーAルータ。
EBGP
External BGP (BGP connection between external peers).
EBGP External BGP(外部の同輩の間のBGP接続)。
External peer
Peer that is in a different Autonomous System than the local
system.
外部の同輩Peer、それはローカルシステムと異なったAutonomous Systemにいます。
Feasible route
An advertised route that is available for use by the recipient.
可能なルートAnは受取人による使用に利用可能なルートの広告を出しました。
IBGP
Internal BGP (BGP connection between internal peers).
IBGP Internal BGP(内部の同輩の間のBGP接続)。
Internal peer
Peer that is in the same Autonomous System as the local system.
ローカルシステムと同じAutonomous Systemにある内部の同輩Peer。
IGP
Interior Gateway Protocol - a routing protocol used to exchange
routing information among routers within a single Autonomous
System.
IGP Interiorゲートウェイプロトコル--ルーティング・プロトコルは以前は独身のAutonomous Systemの中のルータの中でよくルーティング情報を交換していました。
Loc-RIB
The Loc-RIB contains the routes that have been selected by the
local BGP speaker's Decision Process.
Loc-RIB Loc-RIBは地元のBGPスピーカーのDecision Processによって選択されたルートを含んでいます。
NLRI
Network Layer Reachability Information.
NLRIネットワーク層可到達性情報。
Route
A unit of information that pairs a set of destinations with the
attributes of a path to those destinations. The set of
1セットの目的地を経路の属性と対にする情報のAユニットをそれらの目的地に発送してください。 セットします。
Rekhter, et al. Standards Track [Page 5] RFC 4271 BGP-4 January 2006
Rekhter、他 標準化過程[5ページ]RFC4271BGP-2006年1月4日
destinations are systems whose IP addresses are contained in one
IP address prefix carried in the Network Layer Reachability
Information (NLRI) field of an UPDATE message. The path is the
information reported in the path attributes field of the same
UPDATE message.
目的地はIPアドレスがUPDATEメッセージのNetwork Layer Reachability情報(NLRI)分野で運ばれた1つのIPアドレス接頭語に含まれているシステムです。 経路は同じUPDATEメッセージの経路属性分野で報告された情報です。
RIB
Routing Information Base.
経路情報基地にろっ骨を付けてください。
Unfeasible route
A previously advertised feasible route that is no longer available
for use.
実行不可能なルートAは以前に、もう使用に利用可能でない可能なルートの広告を出しました。
1.2. Specification of Requirements
1.2. 要件の仕様
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[RFC2119]で説明されるように本書では解釈されることであるべきですか?
2. Acknowledgements
2. 承認
This document was originally published as [RFC1267] in October 1991, jointly authored by Kirk Lougheed and Yakov Rekhter.
このドキュメントはカーク・ロッキードとヤコフRekhterによって共同で書かれた1991年10月に元々、[RFC1267]として発表されました。
We would like to express our thanks to Guy Almes, Len Bosack, and Jeffrey C. Honig for their contributions to the earlier version (BGP-1) of this document.
このドキュメントの以前のバージョン(BGP-1)への彼らの貢献のためにガイAlmes、レンBosack、およびジェフリー・C.ホニッグに感謝したいと思います。
We would like to specially acknowledge numerous contributions by Dennis Ferguson to the earlier version of this document.
特に、デニスファーガソンによる頻繁な貢献をこのドキュメントの以前のバージョンに承諾したいと思います。
We would like to explicitly thank Bob Braden for the review of the earlier version (BGP-2) of this document, and for his constructive and valuable comments.
このドキュメントの以前のバージョン(BGP-2)のレビュー、および彼の建設的で貴重なコメントについて明らかにボブ・ブレーデンに感謝申し上げます。
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 earlier 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)は、強度、プロフェッショナリズム、および礼儀の強い組み合わせで行動しました。
Certain sections of the document borrowed heavily from IDRP [IS10747], which is the OSI counterpart of BGP. For this, credit should be given to the ANSI X3S3.3 group chaired by Lyman Chapin and to Charles Kunzinger, who was the IDRP editor within that group.
ドキュメントのある一定のセクションはIDRP[IS10747]から大いに借りました。(IDRPはBGPのOSI対応者です)。 これに関しては、ライマン・チェーピンによってまとめられたANSI X3S3.3グループと、そして、チャールズKunzingerにクレジットを与えるべきです。Kunzingerはそのグループの中のIDRPエディタでした。
Rekhter, et al. Standards Track [Page 6] RFC 4271 BGP-4 January 2006
Rekhter、他 標準化過程[6ページ]RFC4271BGP-2006年1月4日
We would also like to thank Benjamin Abarbanel, Enke Chen, Edward Crabbe, Mike Craren, Vincent Gillet, Eric Gray, Jeffrey Haas, Dimitry Haskin, Stephen Kent, John Krawczyk, David LeRoy, Dan Massey, Jonathan Natale, Dan Pei, Mathew Richardson, John Scudder, John Stewart III, Dave Thaler, Paul Traina, Russ White, Curtis Villamizar, and Alex Zinin for their comments.
また、彼らのコメントについてベンジャミンAbarbanel、Enkeチェン、エドワード・クラッベ、マイクCraren、ヴィンセント・ジレ、エリック・グレー、ジェフリー・ハース、ドミトリー・ハスキン、スティーブン・ケント、ジョンKrawczyk、デヴィッド・リロイ、ダン・マッシー、ジョナサンNatale、ダン・ペイ、マシューリチャードソン、ジョンScudder、ジョン・スチュワートIII、デーヴThaler、ポールTraina、ラス・ホワイト、カーティスVillamizar、およびアレックス・ジニンに感謝申し上げます。
We would like to specially acknowledge Andrew Lange for his help in preparing the final version of this document.
特に、彼のご協力のためにこのドキュメントの最終版を準備する際にアンドリュー・ラングを承認したいと思います。
Finally, we would like to thank all the members of the IDR Working Group for their ideas and the support they have given to this document.
最終的に、このドキュメントに与えたのを彼らの考えとサポートのためのIDR作業部会のすべてのメンバーに感謝申し上げます。
3. Summary of Operation
3. 操作の概要
The Border Gateway Protocol (BGP) is an inter-Autonomous System routing protocol. It is built on experience gained with EGP (as defined in [RFC904]) and EGP usage in the NSFNET Backbone (as described in [RFC1092] and [RFC1093]). For more BGP-related information, see [RFC1772], [RFC1930], [RFC1997], and [RFC2858].
ボーダ・ゲイトウェイ・プロトコル(BGP)は相互Autonomous Systemルーティング・プロトコルです。 それはNSFNET BackboneのEGP([RFC904]で定義されるように)と共に行われた経験とEGP用法に建てられます([RFC1092]と[RFC1093]で説明されるように)。 よりBGP関連の情報に関しては、[RFC1772]、[RFC1930]、[RFC1997]、および[RFC2858]を見てください。
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 (ASes) that reachability information traverses. This information is sufficient for constructing a graph of AS connectivity, from which routing loops may be pruned, and, at the AS level, some policy decisions may be enforced.
BGPがシステムを話す第一の機能は他のBGPシステムとネットワーク可到達性情報を交換することです。このネットワーク可到達性情報は可到達性情報が横断するAutonomous Systems(ASes)のリストの上の情報を含んでいます。 この情報はルーティング輪余計なものを取り除かれるかもしれないASの接続性のグラフを作図するのに十分です、そして、ASレベルでは、いくつかの政策決定が励行されるかもしれません。
In the context of this document, we assume that a BGP speaker advertises to its peers only those routes that it uses itself (in this context, a BGP speaker is said to "use" a BGP route if it is the most preferred BGP route and is used in forwarding). All other cases are outside the scope of this document.
このドキュメントの文脈では、私たちは、BGPスピーカー自身がそれが使用するそれらのルートの同輩だけに広告を出すと思います(それが最も都合のよいBGPルートであり、推進に使用されるなら、このような関係においては、BGPスピーカーはBGPルートを「使用する」と言われます)。 このドキュメントの範囲の外に他のすべてのケースがあります。
In the context of this document, the term "IP address" refers to an IP Version 4 address [RFC791].
このドキュメントの文脈では、「IPアドレス」という用語はIPバージョン4アドレス[RFC791]を参照します。
Routing information exchanged via BGP supports only the destination- based forwarding paradigm, which assumes that a router forwards a packet based solely on the destination address carried in the IP header of the packet. This, in turn, reflects the set of policy decisions that can (and cannot) be enforced using BGP. Note that some policies cannot be supported by the destination-based forwarding paradigm, and thus require techniques such as source routing (aka explicit routing) to be enforced. Such policies cannot be enforced using BGP either. For example, BGP does not enable one AS to send
ルート設定情報はBGPを通してパラダイムを進める目的地だけが基礎づけたサポートを交換しました。パラダイムは、ルータが唯一パケットのIPヘッダーで運ばれた送付先アドレスに基づくパケットを進めると仮定します。 これは順番に缶の(and cannot)がBGPを使用することで実施されるという方針決定のセットを反映します。 目的地ベースの推進パラダイムでいくつかの方針を支持できないことに注意してください、そして、その結果、ソースルーティング(別名の明白なルーティング)などのテクニックが励行されるのを必要であってください。 BGPを使用することでそのような方針を励行されることができません。 例えば、BGPは、1ASが発信するのを可能にしません。
Rekhter, et al. Standards Track [Page 7] RFC 4271 BGP-4 January 2006
Rekhter、他 標準化過程[7ページ]RFC4271BGP-2006年1月4日
traffic to a neighboring AS for forwarding to some destination (reachable through but) beyond that neighboring AS, intending that the traffic take a different route to that taken by the traffic originating in the neighboring AS (for that same destination). On the other hand, BGP can support any policy conforming to the destination-based forwarding paradigm.
いくつかの目的地への推進のための隣接しているASへの交通、(届く、しかし)、交通が隣接しているAS(その同じ目的地への)で起こる交通で取られたそれに異なったルートを取ることを意図するその隣接しているASを超えて。 他方では、BGPは目的地ベースの推進パラダイムに従うどんな方針も支持できます。
BGP-4 provides a new set of mechanisms for supporting Classless Inter-Domain Routing (CIDR) [RFC1518, RFC1519]. These mechanisms include support for advertising a set of destinations as an IP prefix and eliminating the concept of a network "class" within BGP. BGP-4 also introduces mechanisms that allow aggregation of routes, including aggregation of AS paths.
BGP-4はClassless Inter-ドメインルート設定(CIDR)[RFC1518、RFC1519]を支持するのに新しいセットのメカニズムを提供します。 これらのメカニズムはIP接頭語として1セットの目的地の広告を出して、BGPの中でネットワーク「クラス」の概念を排除するサポートを含んでいます。 また、BGP-4はAS経路の集合を含むルートの集合を許容するメカニズムを紹介します。
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 (IGP) and common metrics to determine how to route packets within the AS, and using an inter-AS routing protocol to determine how to route packets to other ASes. Since this classic definition was developed, it has become common for a single AS to use several IGPs and, sometimes, several sets of metrics within an AS. The use of the term Autonomous System stresses the fact that, even when multiple IGPs and metrics are used, the administration of an AS appears to other ASes to have a single coherent interior routing plan and presents a consistent picture of the destinations that are reachable through it.
このドキュメントはあらゆる点で'自治のSystem'(AS)という用語を使用します。 Autonomous Systemの古典的な定義はただ一つの技術的な管理の下で、1セットのルータです、ASの中でパケットを発送する方法を決定するのに内部のゲートウェイプロトコル(IGP)と一般的な測定基準を使用して、他のASesにパケットを発送する方法を決定するのに相互ASルーティング・プロトコルを使用して。 この古典的な定義が開発されて以来、独身のASがASの中で数個のIGPsと時々数セットの測定基準を使用するのは一般的になっています。 Autonomous Systemという用語の使用は、ただ一つの論理的な内部のルーティングプランを持つために、複数のIGPsと測定基準が使用されてさえいるとき、ASの管理が他のASesにおいて現れるという事実を強調して、それを通して届いている目的地の一貫した絵を提示します。
BGP uses TCP [RFC793] as its transport protocol. This eliminates the need to implement explicit update fragmentation, retransmission, acknowledgement, and sequencing. BGP listens on TCP port 179. The error notification mechanism used in BGP assumes that TCP supports a "graceful" close (i.e., that all outstanding data will be delivered before the connection is closed).
BGPはトランスポート・プロトコルとしてTCP[RFC793]を使用します。 これは明白なアップデート断片化、「再-トランスミッション」、承認、および配列を実行する必要性を排除します。 BGPはTCPポート179の上で聴きます。 BGPで使用されるエラー通知メカニズムは、TCPが「優雅な」閉鎖を支持すると仮定します(すなわち、接続の前にすべての傑出しているデータを送るのは閉じられます)。
A TCP connection is formed between two systems. They exchange messages to open and confirm the connection parameters.
TCP接続は2台のシステムの間で形成されます。それらは接続パラメタを開いて、確認するメッセージを交換します。
The initial data flow is the portion of the BGP routing table that is allowed by the export policy, called the Adj-Ribs-Out (see 3.2). Incremental updates are sent as the routing tables change. BGP does not require a periodic refresh of the routing table. To allow local policy changes to have the correct effect without resetting any BGP connections, a BGP speaker SHOULD either (a) retain the current version of the routes advertised to it by all of its peers for the duration of the connection, or (b) make use of the Route Refresh extension [RFC2918].
初期のデータフローはAdjあばら骨アウトと呼ばれる輸出方針で許容されているBGP経路指定テーブルの一部(3.2を見る)です。 経路指定テーブルが変化するとき、アップデート増加を送ります。 BGPは周期的にaを必要としません。経路指定テーブルをリフレッシュしてください。 (a) どんなBGP接続もリセットすることのない正しい効果、BGPスピーカーがSHOULDを持つように地方の政策変更を許容するために、接続の持続時間のために同輩のすべてによってそれに広告に掲載されたルートの最新版を保有するか、または(b) Route Refresh拡張子[RFC2918]を利用してください。
Rekhter, et al. Standards Track [Page 8] RFC 4271 BGP-4 January 2006
Rekhter、他 標準化過程[8ページ]RFC4271BGP-2006年1月4日
KEEPALIVE messages may be sent periodically to ensure that the connection is live. 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.
接続が確実に活動的になるようにするために定期的にKEEPALIVEメッセージを送るかもしれません。 誤りか特別な状態に対応してNOTIFICATIONメッセージを送ります。 接続がエラー条件に遭遇するなら、NOTIFICATIONメッセージを送ります、そして、接続は閉じます。
A peer in a different AS is referred to as an external peer, while a peer in the same AS is referred to as an internal peer. Internal BGP and external BGP are commonly abbreviated as IBGP and EBGP.
異なったASの同輩は外部の同輩と呼ばれます、同じASの同輩が内部の同輩と呼ばれますが。 内部のBGPと外部のBGPはIBGPとEBGPが一般的に簡略化されています。
If a particular AS has multiple BGP speakers and is providing transit service for other ASes, 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 IGP used within the AS. For the purpose of this document, it is assumed that a consistent view of the routes exterior to the AS is provided by having all BGP speakers within the AS maintain IBGP with each other.
特定のASが複数のBGPスピーカーがいて、トランジットサービスを他のASesに供給しているなら、ASの中でルーティングの一貫した視点を確実にするために注意しなければなりません。 ASの内部のルートの一貫した意見はASの中で使用されたIGPによって提供されます。 このドキュメントの目的のために、ASの中のすべてのBGPスピーカーにIBGPを維持させることによってASへの外のルートの一貫した意見が互いに提供されると思われます。
This document specifies the base behavior of the BGP protocol. This behavior can be, and is, modified by extension specifications. When the protocol is extended, the new behavior is fully documented in the extension specifications.
このドキュメントはBGPプロトコルのベースの振舞いを指定します。 ファイル拡張仕様書によってあることができて、あって、変更されたこの振舞い。 プロトコルが拡張されているとき、新しい振舞いはファイル拡張仕様書に完全に記録されます。
3.1. Routes: Advertisement and Storage
3.1. ルート: 広告と格納
For the purpose of this protocol, a route is defined as a unit of information that pairs a set of destinations with the attributes of a path to those destinations. The set of destinations are systems whose IP addresses are contained in one IP address prefix that is carried in the Network Layer Reachability Information (NLRI) field of an UPDATE message, and the path is the information reported in the path attributes field of the same UPDATE message.
このプロトコルの目的のために、ルートはそれらの目的地への経路の属性と1セットの目的地を対にする情報のユニットと定義されます。 目的地のセットはIPアドレスがUPDATEメッセージのNetwork Layer Reachability情報(NLRI)分野で運ばれる1つのIPアドレス接頭語に含まれているシステムです、そして、経路は同じUPDATEメッセージの経路属性分野で報告された情報です。
Routes are advertised between BGP speakers in UPDATE messages. Multiple routes that have the same path attributes can be advertised in a single UPDATE message by including multiple prefixes in the NLRI field of the UPDATE message.
UPDATEメッセージのBGPスピーカーの間にルートの広告を出します。 ただ一つのUPDATEメッセージにUPDATEメッセージのNLRI分野の複数の接頭語を含んでいることによって、同じ経路属性を持っている複数のルートは広告を出すことができます。
Routes are stored in the Routing Information Bases (RIBs): namely, the Adj-RIBs-In, the Loc-RIB, and the Adj-RIBs-Out, as described in Section 3.2.
ルートは経路情報基地(RIBs)の中に格納されます: すなわち、セクション3.2における説明されるとしての中のAdj-RIBs、Loc-RIB、および外のAdj-RIBs。
If a BGP speaker chooses to advertise a previously received route, it MAY add to, or modify, the path attributes of the route before advertising it to a peer.
BGPスピーカーが、選ぶなら、以前に容認されたルートの広告を出してください、それ。5月が加えるか、または変更する、同輩にそれの広告を出す前のルートの経路属性。
Rekhter, et al. Standards Track [Page 9] RFC 4271 BGP-4 January 2006
Rekhter、他 標準化過程[9ページ]RFC4271BGP-2006年1月4日
BGP provides mechanisms by which a BGP speaker can inform its peers 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 the destination 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 NLRI can be advertised, or
またはb) 同じNLRIがある交換ルートの広告を出すことができる。
c) the BGP speaker connection can be closed, which implicitly
removes all routes the pair of speakers had advertised to each
other from service.
c) BGPスピーカー接続(それとなくスピーカーの組がサービスから互いに広告を出したすべてのルートを取り外す)は閉店できます。
Changing the attribute(s) of a route is accomplished by advertising a replacement route. The replacement route carries new (changed) attributes and has the same address prefix as the original route.
ルートの属性を変えるのは、交換ルートの広告を出すことによって、達成されます。 交換ルートは、新しい(変える)属性を運んで、元のルートと同じアドレス接頭語を持っています。
3.2. Routing Information Base
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 stores routing information learned
from inbound UPDATE messages that were received from other BGP
speakers. Their contents represent routes that are available
as input to the Decision Process.
a) 中のAdjあばら骨: 情報を発送する中のAdj-RIBs店は他のBGPスピーカーから受け取られた本国行きのUPDATEメッセージから学びました。 それらの内容はDecision Processに入力されるように利用可能なルートを表します。
b) Loc-RIB: The Loc-RIB contains the local routing information the
BGP speaker selected by applying its local policies to the
routing information contained in its Adj-RIBs-In. These are
the routes that will be used by the local BGP speaker. The
next hop for each of these routes MUST be resolvable via the
local BGP speaker's Routing Table.
b) Loc-あばら骨: Loc-RIBはBGPスピーカーが中のAdj-RIBsに含まれたルーティング情報にローカルの方針を適用することによって選択したローカルのルーティング情報を含んでいます。 これらは地元のBGPスピーカーによって使用されるルートです。 それぞれのこれらのルートへの次のホップは地元のBGPスピーカーのルート設定Tableを通して溶解性であるに違いありません。
c) Adj-RIBs-Out: The Adj-RIBs-Out stores information the local BGP
speaker 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 contains 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
概要では、中のAdj-RIBsは同輩によって地元のBGPスピーカーに広告に掲載されている未加工のルーティング情報を含んでいます。 Loc-RIBは地方のBGPによって選択されたルートを含んでいます。
Rekhter, et al. Standards Track [Page 10] RFC 4271 BGP-4 January 2006
Rekhter、他 標準化過程[10ページ]RFC4271BGP-2006年1月4日
speaker's Decision Process; and the Adj-RIBs-Out organizes the routes for advertisement to specific peers (by means of the local speaker's UPDATE messages).
スピーカーの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部はポインタでコピーされる)の選択はプロトコルによって抑制されません。
Routing information that the BGP speaker uses to forward packets (or to construct the forwarding table used for packet forwarding) is maintained in the Routing Table. The Routing Table accumulates routes to directly connected networks, static routes, routes learned from the IGP protocols, and routes learned from BGP. Whether a specific BGP route should be installed in the Routing Table, and whether a BGP route should override a route to the same destination installed by another source, is a local policy decision, and is not specified in this document. In addition to actual packet forwarding, the Routing Table is used for resolution of the next-hop addresses specified in BGP updates (see Section 5.1.3).
BGPスピーカーがパケットを進めること(パケット推進に使用される推進テーブルを組み立てるために)に使用するルート設定情報はルート設定Tableで保守されます。 ルート設定Tableは直接接続されたネットワークにルートを蓄積します、とスタティックルート、IGPプロトコルから学習されたルート、およびルートはBGPから学びました。 BGPルートは、特定のBGPルートがルート設定Tableにインストールされるべきであるかどうかと、別のソースによってインストールされた同じ目的地にルートをくつがえすべきであり、ローカルの政策決定であり、本書では指定されるのでないかどうか 実際のパケット推進に加えて、ルート設定TableはBGPアップデートで指定された次のホップアドレスの解決に使用されます(セクション5.1.3を見てください)。
4. Message Formats
4. メッセージ・フォーマット
This section describes message formats used by BGP.
このセクションはBGPによって使用されたメッセージ・フォーマットについて説明します。
BGP messages are sent over TCP connections. 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 (19 octets).
TCP接続の上にBGPメッセージを送ります。 それを完全に受け取った後にだけメッセージを処理します。 最大のメッセージサイズは4096の八重奏です。 すべての実現が、この最大のメッセージサイズを支持するのに必要です。 送られるかもしれない中で最も小さいメッセージはデータ部(19の八重奏)なしでBGPヘッダーから成ります。
All multi-octet fields are in network byte order.
ネットワークバイトオーダーにはすべてのマルチ八重奏分野があります。
Rekhter, et al. Standards Track [Page 11] RFC 4271 BGP-4 January 2006
Rekhter、他 標準化過程[11ページ]RFC4271BGP-2006年1月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 is included for compatibility; it MUST be
set to all ones.
この16八重奏の分野は互換性のために含まれています。 すべてのものにそれを設定しなければなりません。
Length:
長さ:
This 2-octet unsigned integer indicates the total length of the
message, including the header in octets. Thus, it allows one
to locate the (Marker field of the) next message in the TCP
stream. 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. "padding" of extra data after
the message is not allowed. Therefore, the Length field MUST
have the smallest value required, given the rest of the
message.
この2八重奏の符号のない整数は八重奏にヘッダーを含むメッセージの全長を示します。 その結果、1つがそれで場所を見つけることができる、(マーカー分野、)、TCPの流れにおける次のメッセージ。 Length分野の値は、いつも少なくとも19と、4096以下と、さらに抑制されるかもしれなくて、メッセージタイプに頼ることでなければなりません。 余分なデータがメッセージの後に「水増し」であることは許容されていません。 したがって、Length分野で、メッセージの残りを考えて、最も小さい値を必要としなければなりません。
Type:
以下をタイプしてください。
This 1-octet unsigned integer indicates the type code of the
message. This document defines the following type codes:
この1八重奏の符号のない整数はメッセージのタイプコードを示します。 このドキュメントは以下のタイプコードを定義します:
1 - OPEN
2 - UPDATE
3 - NOTIFICATION
4 - KEEPALIVE
1--開いている2--アップデート3--通知4--KEEPALIVE
[RFC2918] defines one more type code.
[RFC2918]はもうひとつのタイプコードを定義します。
Rekhter, et al. Standards Track [Page 12] RFC 4271 BGP-4 January 2006
Rekhter、他 標準化過程[12ページ]RFC4271BGP-2006年1月4日
4.2. OPEN Message Format
4.2. 開いているメッセージ・フォーマット
After a TCP 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.
TCP接続が確立された後に、それぞれの側によって送られた最初のメッセージはオープンメッセージです。 オープンメッセージが許容できるなら、オープンを確認するKEEPALIVEメッセージは返送されます。
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 (variable) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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番号を示します。
Hold Time:
保持時間:
This 2-octet unsigned integer indicates the number of seconds
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
この2八重奏の符号のない整数は送付者がHold Timerの値のために提案する秒数を示します。 オープンメッセージを受け取り次第、BGPスピーカーは、オープンメッセージに受け取られた構成されたHold TimeとHold Timeについて、より小さいのを使用することによって、Hold Timerの値について計算しなければなりません。 Hold Timeはゼロか少なくとも3秒のどちらかでなければなりません。 実装はHoldに基づいて接続を拒絶するかもしれません。
Rekhter, et al. Standards Track [Page 13] RFC 4271 BGP-4 January 2006
Rekhter、他 標準化過程[13ページ]RFC4271BGP-2006年1月4日
Time. The calculated value indicates the maximum number of
seconds that may elapse between the receipt of successive
KEEPALIVE and/or UPDATE messages from the sender.
時間。 計算された値は連続した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 that is assigned to that BGP
speaker. The value of the BGP Identifier is determined upon
startup and is the same for every local interface and 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 contains a list of optional parameters, in which
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分野の値に従って解釈される可変長フィールドです。
[RFC3392] defines the Capabilities Optional Parameter.
[RFC3392]はCapabilities Optional Parameterを定義します。
The minimum length of the OPEN message is 29 octets (including the message header).
オープンメッセージの最小の長さは29の八重奏(メッセージヘッダーを含んでいて)です。
4.3. UPDATE Message Format
4.3. アップデートメッセージ・フォーマット
UPDATE messages are used to transfer routing information between BGP peers. The information in the UPDATE message can be used to construct a graph that describes the relationships of the various Autonomous Systems. By applying rules to be discussed, routing
UPDATEメッセージは、BGP同輩の間にルーティング情報を移すのに使用されます。 様々なAutonomous Systemsの関係について説明するグラフを作図するのにUPDATEメッセージの情報を使用できます。適用は議論するために統治されます、ルーティング
Rekhter, et al. Standards Track [Page 14] RFC 4271 BGP-4 January 2006
Rekhter、他 標準化過程[14ページ]RFC4271BGP-2006年1月4日
information loops and some other anomalies may be detected and removed from inter-AS routing.
情報輪とある他の例外は、相互ASルーティングから検出されて、取り外されるかもしれません。
An UPDATE message is used to advertise feasible routes that share common path attributes 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 also includes the other fields, as shown below (note, some of the shown fields may not be present in every UPDATE message):
UPDATEメッセージは、共通路属性を同輩と共有する可能なルートの広告を出すか、またはサービスから複数の実行不可能なルートを引っ込めるのに使用されます(3.1を見てください)。 UPDATEメッセージは、同時に、可能なルートの広告を出して、サービスから複数の実行不可能なルートを引っ込めるかもしれません。 UPDATEメッセージは、いつも固定サイズBGPヘッダーを含んでいて、また、他の分野を含んでいます、以下に示すように(注意、示された分野のいくつかがあらゆるUPDATEメッセージに存在しているかもしれないというわけではありません):
+-----------------------------------------------------+
| Withdrawn 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つの八重奏)| +-----------------------------------------------------+ | 経路属性(可変)| +-----------------------------------------------------+ | ネットワーク層可到達性情報(可変)| +-----------------------------------------------------+
Withdrawn Routes Length:
よそよそしいルートの長さ:
This 2-octets unsigned integer indicates the total length of
the Withdrawn Routes field in octets. Its value allows 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、接頭語>としてコード化されます:(>の分野は以下で説明されます)。
+---------------------------+
| Length (1 octet) |
+---------------------------+
| Prefix (variable) |
+---------------------------+
+---------------------------+ | 長さ(1つの八重奏)| +---------------------------+ | 接頭語(変数)| +---------------------------+
Rekhter, et al. Standards Track [Page 15] RFC 4271 BGP-4 January 2006
Rekhter、他 標準化過程[15ページ]RFC4271BGP-2006年1月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 an IP address prefix, followed by
the minimum number of trailing bits needed 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 allows 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 neither the Network Layer
Reachability Information field nor the Path Attribute field is
present in this UPDATE message.
0の値は、Network Layer Reachability情報分野もPath Attribute分野もこのUPDATEメッセージに存在していないのを示します。
Path Attributes:
経路属性:
A variable-length sequence of path attributes is present in
every UPDATE message, except for an UPDATE message that carries
only the withdrawn routes. Each path attribute is a triple
<attribute type, attribute length, attribute value> of variable
length.
経路属性の可変長の系列はあらゆるUPDATEメッセージに存在しています、よそよそしいルートだけを運ぶ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。 コードをタイプしてください。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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に設定されるなら)定義します。
Rekhter, et al. Standards Track [Page 16] RFC 4271 BGP-4 January 2006
Rekhter、他 標準化過程[16ページ]RFC4271BGP-2006年1月4日
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).
Attribute Flags八重奏の2番目の高位のビット(ビット1)はTransitiveビットです。 それは、任意の属性が遷移的であるか(1に設定されるなら)、または非遷移的であるかを(0に設定されるなら)定義します。
For well-known attributes, the Transitive bit MUST be set to 1.
(See Section 5 for a discussion of transitive attributes.)
よく知られる属性において、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).
Attribute Flags八重奏の4番目の高位のビット(ビット3)はExtended Lengthビットです。 それは、Attribute Lengthが1つの八重奏(0に設定されるなら)かそれとも2つの八重奏(1に設定されるなら)であるかを定義します。
The lower-order four bits of the Attribute Flags octet are
unused. They MUST be zero when sent 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, the third and fourth octets of the path attribute contain
the length of the attribute data in octets.
Attribute Flags八重奏のExtended Lengthビットが1に設定されるなら、経路属性の3番目と4番目の八重奏は八重奏における、属性データの長さを含んでいます。
Rekhter, et al. Standards Track [Page 17] RFC 4271 BGP-4 January 2006
Rekhter、他 標準化過程[17ページ]RFC4271BGP-2006年1月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, and their attribute values and uses are as follows:
Path Attributeの残っている八重奏は、属性値を表して、Attribute FlagsとAttribute Type Codeによると、解釈されます。 Attribute Type Codesと、彼らの属性であるとサポートされて、値と用途は以下の通りです:
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 the EGP protocol [RFC904]
1EGP--EGPプロトコルで学習されたネットワークLayer Reachability情報[RFC904]
2 INCOMPLETE - Network Layer Reachability
Information learned by some other means
2INCOMPLETE--ある他の手段によって学習されたネットワークLayer Reachability情報
Usage of this attribute 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経路セグメントは三重の<経路セグメントタイプ、経路セグメントの長さ、経路セグメント価値の>によって表されます。
The path segment type is a 1-octet length field with the
following values defined:
経路セグメントタイプは以下の値が定義されている1八重奏の長さの分野です:
Value Segment Type
値のセグメントタイプ
1 AS_SET: unordered set of ASes a route in the
UPDATE message has traversed
_としての1はセットしました: UPDATEメッセージのルートが横断したASesの順不同のセット
2 AS_SEQUENCE: ordered set of ASes a route in
the UPDATE message has traversed
2 _系列として: UPDATEメッセージのルートが横断したASesの順序集合
The path segment length is a 1-octet length field,
containing the number of ASes (not the number of octets) in
the path segment value field.
経路セグメントの長さは1八重奏の長さの分野です、経路セグメント値の分野のASes(八重奏の数でない)の数を含んでいて。
The path segment value field contains one or more AS
numbers, each encoded as a 2-octet length field.
経路セグメント値の分野は1つ以上のAS番号、2八重奏の長さの分野としてコード化されたそれぞれを含んでいます。
Rekhter, et al. Standards Track [Page 18] RFC 4271 BGP-4 January 2006
Rekhter、他 標準化過程[18ページ]RFC4271BGP-2006年1月4日
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
(unicast) IP address of the router that SHOULD be used as
the next hop to the destinations listed in the Network Layer
Reachability Information field of the UPDATE message.
目的地への次のホップがUPDATEメッセージのNetwork Layer Reachability情報分野に記載したようにこれは使用されていた状態でSHOULDがあるルータの(ユニキャスト)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 unsigned integer. The value of this attribute
MAY be used by a BGP speaker's Decision Process to
discriminate among multiple entry points to a neighboring
autonomous system.
これは4八重奏の符号のない整数である任意の非他動詞属性です。 この属性の値は、複数のエントリー・ポイントの中で隣接している自律システムに差別するのにBGPスピーカーのDecision Processによって使用されるかもしれません。
Usage of this attribute is defined in 5.1.4.
この属性の用法は5.1で.4に定義されます。
e) LOCAL_PREF (Type Code 5):
e) 地方の_PREF(コード5をタイプします):
LOCAL_PREF is a well-known attribute that is a four-octet
unsigned integer. A BGP speaker uses it to inform its other
internal peers of the advertising speaker's degree of
preference for an advertised route.
LOCAL_PREFは4八重奏の符号のない整数であるよく知られる属性です。 BGPスピーカーは、広告スピーカーの広告を出しているルートのための好みの度合いについて他の内部の同輩に知らせるのにそれを使用します。
Usage of this attribute is defined in 5.1.5.
この属性の用法は5.1で.5に定義されます。
f) ATOMIC_AGGREGATE (Type Code 6)
f) 原子_集合(タイプコード6)
ATOMIC_AGGREGATE is a well-known discretionary attribute of
length 0.
ATOMIC_AGGREGATEは長さ0のよく知られる任意の属性です。
Usage of this attribute is defined in 5.1.6.
この属性の用法は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). This SHOULD be the same address as
the one used for the BGP Identifier of the speaker.
AGGREGATORは長さ6の任意の遷移的な属性です。 属性は集合ルート(4つの八重奏として、コード化される)を形成したBGPスピーカーのIPアドレスがあとに続いた集合ルート(2つの八重奏として、コード化される)を形成した最後のAS番号を含んでいます。 このSHOULD、スピーカーのBGP Identifierに使用されるものと同じアドレスになってください。
Usage of this attribute is defined in 5.1.7.
この属性の用法は5.1で.7に定義されます。
Rekhter, et al. Standards Track [Page 19] RFC 4271 BGP-4 January 2006
Rekhter、他 標準化過程[19ページ]RFC4271BGP-2006年1月4日
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
- Withdrawn 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 Withdrawn
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
Withdrawn Routes Length field.
UPDATEメッセージLengthが固定サイズBGPヘッダー、Total Path Attribute Lengthでコード化された値であり、Withdrawn Routes LengthがUPDATEメッセージの可変部分でコード化された値であるところでは、23は、固定サイズBGPヘッダーの結合した長さと、Total Path Attribute Length分野と、Withdrawn 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つの八重奏)| +---------------------------+ | 接頭語(変数)| +---------------------------+
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 an IP address prefix, 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 Withdrawn Routes Length + 2 octets for the Total Path Attribute Length (the value of Withdrawn Routes Length is 0 and the value of Total Path Attribute Length is 0).
UPDATEメッセージの最小の長さは23の八重奏です--Total Path Attribute Length(Withdrawn Routes Lengthの値は0です、そして、Total Path Attribute Lengthの値は0である)のためのWithdrawn Routes Length+2つの八重奏のためのヘッダー+2つの固定八重奏のための19の八重奏。
Rekhter, et al. Standards Track [Page 20] RFC 4271 BGP-4 January 2006
Rekhter、他 標準化過程[20ページ]RFC4271BGP-2006年1月4日
An UPDATE message can advertise, at most, one set of path attributes, but multiple destinations, provided that the destinations share these attributes. All path attributes contained in a given UPDATE message apply to all destinations carried in the NLRI field of the UPDATE message.
UPDATEメッセージは広告を出すことができます、しかし、大部分、1セットの経路属性、複数の目的地で、目的地がこれらの属性を共有すれば。 与えられたUPDATEメッセージに含まれたすべての経路属性がUPDATEメッセージのNLRI分野で運ばれたすべての目的地に適用されます。
An UPDATE message can list multiple routes that are 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 advertised.
UPDATEメッセージはサービスから引っ込められることになっている複数のルートを記載できます。 BGPスピーカーの文脈で明白にルートを特定する目的地(IP接頭語として、言い表される)によってそのような各ルートは特定されます--それが以前に広告に掲載されるBGPスピーカー接続。
An UPDATE message might advertise only routes that are to be withdrawn from service, in which case the message 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分野は存在している必要はありません。
An UPDATE message SHOULD NOT include the same address prefix in the WITHDRAWN ROUTES and Network Layer Reachability Information fields. However, a BGP speaker MUST be able to process UPDATE messages in this form. A BGP speaker SHOULD treat an UPDATE message of this form as though the WITHDRAWN ROUTES do not contain the address prefix.
SHOULD NOTがWITHDRAWN ROUTESとNetwork Layer Reachability情報分野に同じアドレス接頭語を含んでいるというUPDATEメッセージ。 しかしながら、BGPスピーカーはこのフォームでUPDATEメッセージを処理できなければなりません。 まるでWITHDRAWN ROUTESがアドレス接頭語を含んでいないかのようにBGPスピーカーSHOULDはこのフォームに関するUPDATEメッセージを扱います。
4.4. KEEPALIVE Message Format
4.4. KEEPALIVEメッセージ・フォーマット
BGP does not use any TCP-based, keep-alive mechanism to determine if peers are reachable. Instead, KEEPALIVE messages are exchanged between peers often enough 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 messages as a function of the Hold Time interval.
BGPは、同輩が届くかどうか決定するのにどんなTCPベースの生きている生活費メカニズムも使用しません。 代わりに、同輩の間でHold Timerが期限が切れることを引き起こすことができないくらいのしばしばKEEPALIVEメッセージを交換します。 KEEPALIVEメッセージの間の妥当な最大の時間はHold Time間隔の1/3でしょう。 1秒あたり1つより頻繁にKEEPALIVEメッセージを送ってはいけません。 実装はそれがHold Time間隔の機能としてメッセージをKEEPALIVEに送るレートを調整するかもしれません。
If the negotiated Hold Time interval is zero, then periodic KEEPALIVE messages MUST NOT be sent.
交渉されたHold Time間隔がゼロであるなら、周期的なKEEPALIVEメッセージを送ってはいけません。
A KEEPALIVE message consists of only the 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 it is sent.
エラー条件を検出するとき、NOTIFICATIONメッセージを送ります。 それを送る直後BGP接続は閉じられます。
Rekhter, et al. Standards Track [Page 21] RFC 4271 BGP-4 January 2006
Rekhter、他 標準化過程[21ページ]RFC4271BGP-2006年1月4日
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 (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
If no appropriate Error Subcode is defined, then a zero
(Unspecific) value is used for the Error Subcode field.
この1八重奏の符号のない整数は報告された誤りの本質の、より特定の情報を提供します。 各Error Codeには、それに関連している1Error Subcodesがあるかもしれません。 どんな適切な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--悪いメッセージタイプ。
Rekhter, et al. Standards Track [Page 22] RFC 4271 BGP-4 January 2006
Rekhter、他 標準化過程[22ページ]RFC4271BGP-2006年1月4日
OPEN Message Error subcodes:
オープンMessage Error部分符号:
1 - Unsupported Version Number.
2 - Bad Peer AS.
3 - Bad BGP Identifier.
4 - Unsupported Optional Parameter.
5 - [Deprecated - see Appendix A].
6 - Unacceptable Hold Time.
1--サポートされないバージョン番号。 2--悪い同輩 3--悪いBGP識別子。 4--サポートされない任意のパラメタ。 5--[推奨しない--、見る、Appendix A] 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 - [Deprecated - see Appendix A].
8 - Invalid NEXT_HOP Attribute.
9 - Optional Attribute Error.
10 - Invalid Network Field.
11 - Malformed AS_PATH.
1--奇形の属性リスト。 2--認識されていないよく知られる属性。 3--よく知られる属性を逃します。 4--属性は誤りに旗を揚げさせます。 5--長さの誤りを結果と考えてください。 6--無効の発生源属性。 7--[推奨しない--、見る、Appendix A] 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 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の八重奏(メッセージヘッダーを含んでいて)です。
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. 任意の非他動詞。
Rekhter, et al. Standards Track [Page 23] RFC 4271 BGP-4 January 2006
Rekhter、他 標準化過程[23ページ]RFC4271BGP-2006年1月4日
BGP implementations MUST recognize all well-known attributes. Some of these attributes are mandatory and MUST be included in every UPDATE message that contains NLRI. Others are discretionary and MAY or MAY NOT be sent in a particular UPDATE message.
BGP実装はすべてのよく知られる属性を認識しなければなりません。 これらの属性のいくつかを義務的であり、NLRIを含むあらゆるUPDATEメッセージに含まなければなりません。 他のものを任意であり、特定のUPDATEメッセージで送るかもしれません。
Once a BGP peer has updated any well-known attributes, it MUST pass these attributes to its peers in any updates it transmits.
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 an unrecognized transitive optional attribute is accepted and passed 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 a 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 MUST NOT be 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ビットの設定で、八重奏に旗を揚げさせます認識されていない任意の属性の取り扱いが決定している。 認識されていない遷移的な任意の属性SHOULDを受け入れている経路。 認識されていない遷移的な任意の属性がある経路が他のBGP同輩に受け入れられて、渡されるなら、その経路の認識されていない遷移的な任意の属性を通過しなければなりません、経路と共に、1に設定されたAttribute Flags八重奏におけるPartialビットをもっている他の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 BGP speaker 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 BGP speakers in the path.
新しいです、遷移的な任意の属性は創始者か経路のいかなる他のBGPスピーカーによっても経路に付けられるかもしれません。 それらが創始者によって付けられないなら、Attribute Flags八重奏におけるPartialビットは1に設定されます。 付けの新しい非他動詞任意の属性のための規則は特定の属性の本質によるでしょう。 それぞれの新しい非他動詞任意の属性のドキュメンテーションがそのような規則を含んでいると予想されるでしょう(MULTI_EXIT_DISC属性の記述は作例を示します)。 すべての任意の属性(遷移的なものと同様に非遷移的な)が、経路のBGPスピーカーによるアップデートされるのと(適切。)であるかもしれません。
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 UPDATE messages that are out of order.
SHOULDがUPDATEメッセージの中で属性タイプの昇順で経路属性を命令するUPDATEメッセージの送付者。 不適切なUPDATEメッセージの中で経路属性を扱うようにUPDATEメッセージの受信機を準備しなければなりません。
The same attribute (attribute with the same type) cannot appear more than once within the Path Attributes field of a particular UPDATE message.
同じ属性(同じタイプで、結果と考える)は特定のUPDATEメッセージのPath Attributes分野の中で一度より多く見えることができません。
Rekhter, et al. Standards Track [Page 24] RFC 4271 BGP-4 January 2006
Rekhter、他 標準化過程[24ページ]RFC4271BGP-2006年1月4日
The mandatory category refers to an attribute that MUST be present in both IBGP and EBGP exchanges if NLRI are contained in the UPDATE message. Attributes classified as optional for the purpose of the protocol extension mechanism may be purely discretionary, discretionary, required, or disallowed in certain contexts.
義務的なカテゴリはNLRIがUPDATEメッセージに含まれているならIBGPとEBGP交換の両方に存在しなければならない属性について言及します。 プロトコル拡張機能の目的のために任意であるとして分類された属性は、純粋に任意、任意、必要であるか、またはある文脈で禁じられるかもしれません。
attribute EBGP IBGP
ORIGIN mandatory mandatory
AS_PATH mandatory mandatory
NEXT_HOP mandatory mandatory
MULTI_EXIT_DISC discretionary discretionary
LOCAL_PREF see Section 5.1.5 required
ATOMIC_AGGREGATE see Section 5.1.6 and 9.1.4
AGGREGATOR discretionary discretionary
義務的な_DISC任意の任意のMULTI_EXIT LOCAL_PREFがセクション5.1.5を見るのが義務的な義務的なAS_PATH義務的な義務的なネクスト_HOPがATOMIC_AGGREGATEを必要としたのが義務的な属性EBGP IBGP ORIGINが、セクション5.1 .6と9.1が.4AGGREGATOR任意であることがわかる、任意
5.1. Path Attribute Usage
5.1. 経路属性用法
The usage of each BGP path attribute is described in the following clauses.
それぞれのBGP経路属性の用法は以下の節で説明されます。
5.1.1. ORIGIN
5.1.1. 発生源
ORIGIN is a well-known mandatory attribute. The ORIGIN attribute is generated by the speaker that originates the associated routing information. Its value SHOULD NOT be changed by any other speaker.
ORIGINはよく知られる義務的な属性です。 ORIGIN属性は関連ルーティング情報を溯源するスピーカーによって生成されます。 SHOULD NOTを評価してください。それ、いかなる他のスピーカーによっても変えられます。
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 it learned from another BGP speaker's UPDATE message, it modifies 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 an internal
peer, the advertising speaker SHALL NOT modify the AS_PATH
attribute associated with the route.
a) 与えられたBGPスピーカーが内部の同輩にルートの広告を出すとき、広告スピーカーSHALL NOTはルートに関連しているAS_PATH属性を変更します。
b) When a given BGP speaker advertises the route to an external
peer, the advertising speaker updates the AS_PATH attribute as
follows:
b) 与えられたBGPスピーカーが外部の同輩にルートの広告を出すとき、広告スピーカーは以下のAS_PATH属性をアップデートします:
Rekhter, et al. Standards Track [Page 25] RFC 4271 BGP-4 January 2006
Rekhter、他 標準化過程[25ページ]RFC4271BGP-2006年1月4日
1) if the first path segment of the AS_PATH is of type
AS_SEQUENCE, the local system prepends its own AS number as
the last element of the sequence (put it in the leftmost
position with respect to the position of octets in the
protocol message). If the act of prepending will cause an
overflow in the AS_PATH segment (i.e., more than 255 ASes),
it SHOULD prepend a new segment of type AS_SEQUENCE and
prepend its own AS number to this new segment.
_1) ASの最初の経路セグメントであるなら、タイプAS_SEQUENCE(系列(プロトコルメッセージにおける八重奏の位置に関して一番左位置にそれを入れる)の最後の原理としてのローカルシステムのprependsのそれ自身のAS番号)にはPATHがあります。 prependingする行為がAS_PATHセグメント(すなわち、255ASes)でオーバーフローを引き起こして、それがタイプAS_SEQUENCEのSHOULD prependのa新しいセグメントであり、prependがそれ自身のものであるなら、ASはこれほど新しくセグメントに付番します。
2) if the first path segment of the AS_PATH is of type AS_SET,
the local system prepends a new path segment of type
AS_SEQUENCE to the AS_PATH, including its own AS number in
that segment.
2) AS_の最初の経路セグメントであるなら、タイプAS_SETにはPATHがあって、ローカルシステムprependsはそのセグメントでそれ自身のAS番号を含むAS_PATHへのタイプAS_SEQUENCEの新しい経路セグメントです。
3) if the AS_PATH is empty, the local system creates a path
segment of type AS_SEQUENCE, places its own AS into that
segment, and places that segment into the AS_PATH.
3) AS_PATHが空であるなら、ローカルシステムは、タイプAS_SEQUENCEの経路セグメントを作成して、それ自身のASをそのセグメントに置いて、AS_PATHにそのセグメントを置きます。
When a BGP speaker originates a route then:
BGPスピーカーがその時ルートを溯源するとき:
a) the originating speaker includes its own AS number in a path
segment, of type AS_SEQUENCE, in the AS_PATH attribute of all
UPDATE messages sent to an external peer. In this case, the AS
number of the originating speaker's autonomous system will be
the only entry the path segment, and this path segment will be
the only segment in the AS_PATH attribute.
a) 起因しているスピーカーはタイプAS_SEQUENCEの経路セグメントでそれ自身のAS番号を入れます、外部の同輩に送られたすべてのUPDATEメッセージのAS_PATH属性で。 この場合、起因しているスピーカーの自律システムのAS番号は唯一のエントリーが経路セグメントであったならそうするでしょう、そして、この経路セグメントはAS_PATH属性で唯一のセグメントになるでしょう。
b) the originating speaker includes an empty AS_PATH attribute in
all UPDATE messages sent to internal peers. (An empty AS_PATH
attribute is one whose length field contains the value zero).
b) 起因しているスピーカーは内部の同輩に送られたすべてのUPDATEメッセージで空のAS_PATH属性を入れます。 (空のAS_PATH属性は長さの分野が値ゼロを含むものです。)
Whenever the modification of the AS_PATH attribute calls for including or prepending the AS number of the local system, the local system MAY include/prepend more than one instance of its own AS number in the AS_PATH attribute. This is controlled via local configuration.
AS_PATH属性の変更が、ローカルシステムのAS番号を含んでいるか、またはprependingするように求めるときはいつも、ローカルシステムはAS_PATH属性におけるそれ自身のAS番号の1つのインスタンスより/prependを含むかもしれません。 これは地方の構成で制御されます。
5.1.3. NEXT_HOP
5.1.3. 次の_ホップ
The NEXT_HOP is a well-known mandatory attribute that defines the IP address of the router that SHOULD be used as the next hop to the destinations listed in the UPDATE message. The NEXT_HOP attribute is calculated as follows:
目的地への次のホップがUPDATEメッセージに記載したようにネクスト_HOPは使用されていた状態でSHOULDがあるルータのIPアドレスを定義するよく知られる義務的な属性です。 ネクスト_HOP属性は以下の通り計算されます:
1) When sending a message to an internal peer, if the route is not
locally originated, the BGP speaker SHOULD NOT modify the
NEXT_HOP attribute unless it has been explicitly configured to
announce its own IP address as the NEXT_HOP. When announcing a
1) ルートが局所的に溯源されないなら内部の同輩にメッセージを送るとき、それが_ネクストHOPとしてそれ自身のIPアドレスを発表するために明らかに構成されていない場合、BGPスピーカーSHOULD NOTはネクスト_HOP属性を変更します。 aを発表します。
Rekhter, et al. Standards Track [Page 26] RFC 4271 BGP-4 January 2006
Rekhter、他 標準化過程[26ページ]RFC4271BGP-2006年1月4日
locally-originated route to an internal peer, the BGP speaker
SHOULD use the interface address of the router through which
the announced network is reachable for the speaker as the
NEXT_HOP. If the route is directly connected to the speaker,
or if the interface address of the router through which the
announced network is reachable for the speaker is the internal
peer's address, then the BGP speaker SHOULD use its own IP
address for the NEXT_HOP attribute (the address of the
interface that is used to reach the peer).
内部の同輩への局所的に溯源されたルート、BGPスピーカーSHOULDはスピーカーにとって、発表されたネットワークが_ネクストHOPとして届いているルータのインターフェース・アドレスを使用します。 ルートが直接スピーカーに接続されるか、またはスピーカーにとって、発表されたネットワークが届いているルータのインターフェース・アドレスが内部の同輩のアドレスであるなら、BGPスピーカーSHOULDはネクスト_HOP属性(同輩に届くのに使用されるインタフェースのアドレス)にそれ自身のIPアドレスを使用します。
2) When sending a message to an external peer, X, and the peer is
one IP hop away from the speaker:
2) 発信するとき、外部の同輩、X、および同輩へのメッセージはスピーカーからの遠くの1つのIPホップです:
- If the route being announced was learned from an internal
peer or is locally originated, the BGP speaker can use an
interface address of the internal peer router (or the
internal router) through which the announced network is
reachable for the speaker for the NEXT_HOP attribute,
provided that peer X shares a common subnet with this
address. This is a form of "third party" NEXT_HOP attribute.
- 発表されるルートが内部の同輩から学習されたか、または局所的に溯源されるなら、BGPスピーカーはスピーカーにとって、発表されたネットワークがネクスト_HOP属性のために届いている内部の同輩ルータ(または、内部のルータ)のインターフェース・アドレスを使用できます、同輩Xがこのアドレスと一般的なサブネットを共有すれば。 これはHOPが結果と考える「第三者」ネクスト_のフォームです。
- Otherwise, if the route being announced was learned from an
external peer, the speaker can use an IP address of any
adjacent router (known from the received NEXT_HOP attribute)
that the speaker itself uses for local route calculation in
the NEXT_HOP attribute, provided that peer X shares a common
subnet with this address. This is a second form of "third
party" NEXT_HOP attribute.
- さもなければ、発表されるルートが外部の同輩から学習されたなら、スピーカーはスピーカー自身がローカルなルート計算にネクスト_HOP属性に使用するどんな隣接しているルータ(容認されたネクスト_HOP属性から、知られている)のIPアドレスも使用できます、同輩Xがこのアドレスと一般的なサブネットを共有すれば。 これはHOPが結果と考える「第三者」ネクスト_の2番目のフォームです。
- Otherwise, if the external peer to which the route is being
advertised shares a common subnet with one of the interfaces
of the announcing BGP speaker, the speaker MAY use the IP
address associated with such an interface in the NEXT_HOP
attribute. This is known as a "first party" NEXT_HOP
attribute.
- さもなければ、ルートが広告に掲載されている外部の同輩が発表しているBGPスピーカーのインタフェースの1つと一般的なサブネットを共有するなら、スピーカーはネクスト_HOP属性にそのようなインタフェースに関連しているIPアドレスを使用するかもしれません。 これは「最初に、パーティー」ネクスト_HOP属性として知られています。
- By default (if none of the above conditions apply), the BGP
speaker SHOULD use the IP address of the interface that the
speaker uses to establish the BGP connection to peer X in the
NEXT_HOP attribute.
- デフォルトで(上記の状態のいずれも適用されないなら)、BGPスピーカーSHOULDはスピーカーがネクスト_HOP属性でBGP接続を同輩Xに証明するのに使用するインタフェースのIPアドレスを使用します。
3) When sending a message to an external peer X, and the peer is
multiple IP hops away from the speaker (aka "multihop EBGP"):
3) 外部の同輩X、および同輩にメッセージを送るのが、そうときに、複数のIPがスピーカー(通称「マルチホップEBGP」)から遠くを跳びます:
- The speaker MAY be configured to propagate the NEXT_HOP
attribute. In this case, when advertising a route that the
speaker learned from one of its peers, the NEXT_HOP attribute
of the advertised route is exactly the same as the NEXT_HOP
- スピーカーは、ネクスト_HOP属性を伝播するために構成されるかもしれません。 この場合スピーカーが同輩のひとりから学んだルートの広告を出すとき、広告を出しているルートのネクスト_HOP属性はまさに_ネクストHOPと同じです。
Rekhter, et al. Standards Track [Page 27] RFC 4271 BGP-4 January 2006
Rekhter、他 標準化過程[27ページ]RFC4271BGP-2006年1月4日
attribute of the learned route (the speaker does not modify
the NEXT_HOP attribute).
学術的ルート(スピーカーはネクスト_HOP属性を変更しない)の属性。
- By default, the BGP speaker SHOULD use the IP address of the
interface that the speaker uses in the NEXT_HOP attribute to
establish the BGP connection to peer X.
- デフォルトで、BGPスピーカーSHOULDはスピーカーがBGP接続を同輩Xに証明するのにネクスト_HOP属性に使用するインタフェースのIPアドレスを使用します。
Normally, the NEXT_HOP attribute is chosen such that the shortest available path will be taken. A BGP speaker MUST be able to support the disabling advertisement of third party NEXT_HOP attributes in order to handle imperfectly bridged media.
通常、ネクスト_HOP属性は、最も短い利用可能な経路を取るように選ばれています。 BGPスピーカーは、不完全にブリッジしているメディアを扱うために第三者ネクスト_HOP属性の無効にする広告をサポートすることができなければなりません。
A route originated by a BGP speaker SHALL NOT be advertised to a peer using an address of that peer as NEXT_HOP. A BGP speaker SHALL NOT install a route with itself as the next hop.
ルートはBGPでスピーカーSHALL NOTを溯源しました。ネクスト_HOPとしてその同輩のアドレスを使用することで同輩に広告を出してください。 BGPスピーカーSHALL NOTは次のホップとしてそれ自体でルートをインストールします。
The NEXT_HOP attribute is used by the BGP speaker to determine the actual outbound interface and immediate next-hop address that SHOULD be used to forward transit packets to the associated destinations.
ネクスト_HOP属性は、トランジットパケットを関連目的地に送るのにおいて使用されていた状態でSHOULDがある実際の外国行きのインタフェースと即座の次のホップアドレスを決定するのにBGPスピーカーによって使用されます。
The immediate next-hop address is determined by performing a recursive route lookup operation for the IP address in the NEXT_HOP attribute, using the contents of the Routing Table, selecting one entry if multiple entries of equal cost exist. The Routing Table entry that resolves the IP address in the NEXT_HOP attribute will always specify the outbound interface. If the entry specifies an attached subnet, but does not specify a next-hop address, then the address in the NEXT_HOP attribute SHOULD be used as the immediate next-hop address. If the entry also specifies the next-hop address, this address SHOULD be used as the immediate next-hop address for packet forwarding.
アドレスが等しい費用の多回入国が存在しているなら1つのエントリーを選択して、ルート設定Tableのコンテンツを使用して、ネクスト_HOP属性におけるIPアドレスのための再帰的なルートルックアップ操作を実行しながら決定している即座の次のホップ。 ネクスト_HOP属性におけるIPアドレスを決議するルート設定Tableエントリーはいつも外国行きのインタフェースを指定するでしょう。 エントリーが付属サブネットを指定しますが、次のホップアドレスは指定しないなら、_ネクストHOPのアドレスがSHOULDを結果と考えます。即座の次のホップアドレスとして、使用されてください。 また、エントリーが次のホップアドレスを指定するなら、これはSHOULDを扱います。即座の次のホップアドレスとして、パケット推進には、使用されてください。
5.1.4. MULTI_EXIT_DISC
5.1.4. マルチ_出口_ディスク
The MULTI_EXIT_DISC is an optional non-transitive attribute that is intended to 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, called a metric. All other factors being equal, the exit point with the lower metric SHOULD be preferred. If received over EBGP, the MULTI_EXIT_DISC attribute MAY be propagated over IBGP to other BGP speakers within the same AS (see also 9.1.2.2). The MULTI_EXIT_DISC attribute received from a neighboring AS MUST NOT be propagated to other neighboring ASes.
MULTI_EXIT_DISCは複数の出口の中で差別するのに外部(相互AS)のリンクの上に使用されることを意図する任意の非他動詞属性であるかエントリーが同じ隣接しているASを示します。 MULTI_EXIT_DISC属性の値はメートル法でaと呼ばれる4八重奏の符号のない数です。 同輩、下側のメートル法のSHOULDが好まれているエキジットポイントである他のすべての要素。 また、見てください。EBGPの上に受け取るなら、同じASの中でIBGPの上でMULTI_EXIT_DISC属性を他のBGPスピーカーに伝播するかもしれない、(9.1 .2 .2)。 MULTI_EXIT_DISC属性は隣接しているAS MUST NOTから受信しました。他の隣接しているASesに伝播されます。
A BGP speaker MUST implement a mechanism (based on local configuration) that allows the MULTI_EXIT_DISC attribute to be removed from a route. If a BGP speaker is configured to remove the
BGPスピーカーはMULTI_EXIT_DISC属性がルートから取り除かれるのを許容するメカニズム(地方の構成に基づいている)を実装しなければなりません。 BGPスピーカーは、取り外すために構成されます。
Rekhter, et al. Standards Track [Page 28] RFC 4271 BGP-4 January 2006
Rekhter、他 標準化過程[28ページ]RFC4271BGP-2006年1月4日
MULTI_EXIT_DISC attribute from a route, then this removal MUST be done prior to determining the degree of preference of the route and prior to performing route selection (Decision Process phases 1 and 2).
DISCがルートから結果と考えるMULTI_EXIT_、そして、ルートの好みの度合いを決定する前とルート選択(決定Processフェーズ1と2)を実行する前に、この取り外しをしなければなりません。
An implementation MAY also (based on local configuration) alter the value of the MULTI_EXIT_DISC attribute received over EBGP. If a BGP speaker is configured to alter the value of the MULTI_EXIT_DISC attribute received over EBGP, then altering the value MUST be done prior to determining the degree of preference of the route and prior to performing route selection (Decision Process phases 1 and 2). See Section 9.1.2.2 for necessary restrictions on this.
また、実装はEBGPの上に受け取られたMULTI_EXIT_DISC属性の値を変更するかもしれません(地方の構成に基づいています)。 BGPスピーカーがEBGPの上に受け取られたMULTI_EXIT_DISC属性の値を変更するために構成されるなら、ルートの好みの度合いを決定する前とルート選択(決定Processフェーズ1と2)を実行する前に、値を変更しなければなりません。 セクション9.1を見てください。.2 .2 これにおける必要な制限のために。
5.1.5. LOCAL_PREF
5.1.5. 地方の_PREF
LOCAL_PREF is a well-known attribute that SHALL be included in all UPDATE messages that a given BGP speaker sends to other internal peers. A BGP speaker SHALL calculate the degree of preference for each external route based on the locally-configured policy, and include the degree of preference when advertising a route to its internal peers. The higher degree of preference MUST be preferred. A BGP speaker uses the degree of preference learned via LOCAL_PREF in its Decision Process (see Section 9.1.1).
LOCAL_PREFはよく知られる属性です。SHALLは与えられたBGPスピーカーが他の内部の同輩に発信するというすべてのUPDATEメッセージに含まれています。 BGPスピーカーSHALLは局所的に構成された方針に基づく各外部経路のための好みの度合いについて計算して、内部の同輩にルートの広告を出すとき、好みの度合いを含んでいます。 より高度合いの好みを好まなければなりません。 BGPスピーカーはDecision ProcessのLOCAL_PREFを通して学習された好みの度合いを使用します(セクション9.1.1を見てください)。
A BGP speaker MUST NOT include this attribute in UPDATE messages it sends to external peers, except in the case of BGP Confederations [RFC3065]. If it is contained in an UPDATE message that is received from an external peer, then this attribute MUST be ignored by the receiving speaker, except in the case of BGP Confederations [RFC3065].
BGPスピーカーはそれが外部の同輩に送るUPDATEメッセージでこの属性を入れてはいけません、BGP Confederations[RFC3065]に関するケースを除いて。 それが外部の同輩から受け取られるUPDATEメッセージに含まれているなら、受信スピーカーはこの属性を無視しなければなりません、BGP Confederations[RFC3065]に関するケースを除いて。
5.1.6. ATOMIC_AGGREGATE
5.1.6. 原子_集合
ATOMIC_AGGREGATE is a well-known discretionary attribute.
ATOMIC_AGGREGATEはよく知られる任意の属性です。
When a BGP speaker aggregates several routes for the purpose of advertisement to a particular peer, the AS_PATH of the aggregated route normally includes an AS_SET formed from the set of ASes from which the aggregate was formed. In many cases, the network administrator can determine if the aggregate can safely be advertised without the AS_SET, and without forming route loops.
BGPスピーカーが特定の同輩への広告の目的のために数個のルートに集めるとき、通常、集められたルートのAS_PATHは集合が形成されたASesのセットから形成されたAS_SETを含んでいます。 多くの場合、ネットワーク管理者は、集合がAS_SETなしでルート輪を形成することなしで安全に広告を出すことができるかどうかと決心できます。
If an aggregate excludes at least some of the AS numbers present in the AS_PATH of the routes that are aggregated as a result of dropping the AS_SET, the aggregated route, when advertised to the peer, SHOULD include the ATOMIC_AGGREGATE attribute.
集合が少なくとも同輩に広告を出すとAS_SET、集められたルートを下げることの結果、集められるルートのAS_PATHの現在のAS番号のいくつかを除くなら、SHOULDはATOMIC_AGGREGATE属性を含んでいます。
Rekhter, et al. Standards Track [Page 29] RFC 4271 BGP-4 January 2006
Rekhter、他 標準化過程[29ページ]RFC4271BGP-2006年1月4日
A BGP speaker that receives a route with the ATOMIC_AGGREGATE attribute SHOULD NOT remove the attribute when propagating the route to other speakers.
他のスピーカーにルートを伝播するとき、ATOMIC_AGGREGATE属性SHOULD NOTと共にルートを受け取るBGPスピーカーは属性を取り除きます。
A BGP speaker that receives a route with the ATOMIC_AGGREGATE attribute MUST NOT make any NLRI of that route more specific (as defined in 9.1.4) when advertising this route to other BGP speakers.
ATOMIC_AGGREGATE属性があるルートを受け取るBGPスピーカーがそのルートの少しのNLRIもより特定にしてはいけない、(中で定義される、9.1、.4、)、他のBGPスピーカーにこのルートの広告を出すとき。
A BGP speaker that receives a route with the ATOMIC_AGGREGATE attribute needs to be aware of the fact that the actual path to destinations, as specified in the NLRI of the route, while having the loop-free property, may not be the path specified in the AS_PATH attribute of the route.
ATOMIC_AGGREGATE属性があるルートを受け取るBGPスピーカーは、目的地への無輪の特性を持っている間、ルートのNLRIで指定される実際の経路がルートのAS_PATH属性で指定された経路でないかもしれないという事実を知る必要があります。
5.1.7. AGGREGATOR
5.1.7. アグリゲータ
AGGREGATOR is an optional transitive attribute, which MAY be included in updates that are formed by aggregation (see Section 9.2.2.2). A BGP speaker that performs route aggregation MAY add the AGGREGATOR attribute, which SHALL contain its own AS number and IP address. The IP address SHOULD be the same as the BGP Identifier of the speaker.
(属性は集合によって形成されるアップデートに含まれるかもしれません)。セクション9.2を見てください。AGGREGATORが任意の遷移的な属性である、(.2 .2)。 ルート集合を実行するBGPスピーカーはAGGREGATOR属性、どのSHALLがそれ自身のAS番号を含んでいるか、そして、およびIPアドレスを加えるかもしれません。 IPはSHOULDを扱います。スピーカーのBGP Identifierと同じにしてください。
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 (unless it is explicitly stated that no NOTIFICATION message is to be sent and the BGP connection is not to be closed). If no Error Subcode is specified, then a zero MUST be used.
ここで説明された状態のどれかを検出するとき、示されたError CodeがあるNOTIFICATIONメッセージ(Error Subcode、およびData分野)を送ります、そして、BGP接続は閉じます(BGP接続をどんなNOTIFICATIONメッセージも送られないことであり、閉店させていてはいけないのは明らかに述べられない場合)。 Error Subcodeが全く指定されないなら、ゼロを使用しなければなりません。
The phrase "the BGP connection is closed" means the TCP connection has been closed, the associated Adj-RIB-In has been cleared, and all resources for that BGP connection have been deallocated. Entries in the Loc-RIB associated with the remote peer are marked as invalid. The local system recalculates its best routes for the destinations of the routes marked as invalid. Before the invalid routes are deleted from the system, it advertises, to its peers, either withdraws for the routes marked as invalid, or the new best routes before the invalid routes are deleted from the system.
「BGP接続は閉じられること」が、TCP接続が持っていることを意味する句が閉じられて、中の関連Adj-RIBがきれいにされました、そして、そのBGP接続へのすべてのリソースが「反-割り当て」られました。 リモート同輩に関連しているLoc-RIBのエントリーは無効であることが示されます。 最善が無効であるとマークされたルートの目的地に発送するローカルシステムrecalculates。 無効のルートがシステムから削除される前に、同輩に広告を出すか、どちらかが無効であるとマークされたルートに引き下がるか、または新しい以前病人が発送する中で最も良いルートはシステムから削除されます。
Unless specified explicitly, the Data field of the NOTIFICATION message that is sent to indicate an error is empty.
明らかに指定されない場合、誤りを示すために送られるNOTIFICATIONメッセージのData分野は人影がありません。
Rekhter, et al. Standards Track [Page 30] RFC 4271 BGP-4 January 2006
Rekhter、他 標準化過程[30ページ]RFC4271BGP-2006年1月4日
6.1. Message Header Error Handling
6.1. メッセージヘッダーエラー処理
All errors detected while processing the Message Header MUST be indicated by sending the NOTIFICATION message with the Error Code Message Header Error. The Error Subcode elaborates on the specific nature of the error.
Error Code Message Header Errorと共にNOTIFICATIONメッセージを送ることによって、Message Headerを処理している間に検出されたすべての誤りを示さなければなりません。 Error Subcodeは誤りの特定の本質について詳しく説明します。
The expected value of the Marker field of the message header is all ones. If the Marker field of the message header is not as expected, then a synchronization error has occurred and the Error Subcode MUST be set to Connection Not Synchronized.
メッセージヘッダーのMarker分野の期待値はすべてものです。 予想されるとしてメッセージヘッダーのMarker分野がないなら、同期誤りは発生しました、そして、Error SubcodeはConnection Not Synchronizedに用意ができなければなりません。
If at least one of the following is true:
少なくとも以下の1つが本当であるなら:
- if the Length field of the message header is less than 19 or
greater than 4096, or
- またはメッセージヘッダーのLength分野があるなら19以上より4096。
- if the Length field of an OPEN message is less than the minimum
length of the OPEN message, or
- またはオープンメッセージのLength分野がオープンメッセージの最小の長さ以下であるなら。
- if the Length field of an UPDATE message is less than the
minimum length of the UPDATE message, or
- またはUPDATEメッセージのLength分野がUPDATEメッセージの最小の長さ以下であるなら。
- if the Length field of a KEEPALIVE message is not equal to 19,
or
- またはKEEPALIVEメッセージのLength分野が19と等しくないなら。
- if the Length field of a NOTIFICATION message is less than the
minimum length of the NOTIFICATION message,
- NOTIFICATIONメッセージのLength分野がNOTIFICATIONメッセージの最小の長さ以下であるなら
then the Error Subcode MUST be set to Bad Message Length. The Data field MUST contain the erroneous Length field.
そして、Error SubcodeはBad Message Lengthに用意ができなければなりません。 Data分野は誤ったLength分野を含まなければなりません。
If the Type field of the message header is not recognized, then the Error Subcode MUST be set to Bad Message Type. The Data field MUST contain 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 MUST be indicated by sending the NOTIFICATION message with the 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 in the Version field of the received OPEN message is not supported, then the Error Subcode MUST be 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
受信されたオープンメッセージのバージョン分野のバージョン番号がサポートされないなら、Error SubcodeはUnsupportedバージョンNumberに用意ができなければなりません。 にみられるようにData分野が2八重奏の符号のない整数である、(。(符号のない整数はリモートBGP同輩が付けたバージョンほど最も大きくて、局所的にサポートしているバージョン番号を示しません)。
Rekhter, et al. Standards Track [Page 31] RFC 4271 BGP-4 January 2006
Rekhter、他 標準化過程[31ページ]RFC4271BGP-2006年1月4日
the received OPEN message), or if the smallest, locally-supported version number is greater than the version the remote BGP peer bid, then the smallest, locally-supported version number.
受信されたオープンメッセージ)、最も小さくて、局所的にサポートしているバージョン番号であるなら、次にリモートBGP同輩が付けたバージョンより大きい最も小さくて、局所的にサポートしているバージョン数はそうです。
If the Autonomous System field of the OPEN message is unacceptable, then the Error Subcode MUST be 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 that 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 MUST be set to Bad BGP Identifier. Syntactic correctness means that the BGP Identifier field represents a valid unicast 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 MUST be set to Unsupported Optional Parameters.
オープンメッセージのOptional Parametersの1つが認識されないなら、Error SubcodeはUnsupported Optional Parametersに用意ができなければなりません。
If one of the Optional Parameters in the OPEN message is recognized, but is malformed, then the Error Subcode MUST be set to 0 (Unspecific).
オープンメッセージのOptional Parametersの1つが認識されますが、奇形であるなら、Error Subcodeは0(Unspecific)に用意ができなければなりません。
6.3. UPDATE Message Error Handling
6.3. アップデートメッセージエラー処理
All errors detected while processing the UPDATE message MUST be indicated by sending the NOTIFICATION message with the Error Code UPDATE Message Error. The error subcode elaborates on the specific nature of the error.
Error Code UPDATE Message Errorと共にNOTIFICATIONメッセージを送ることによって、UPDATEメッセージを処理している間に検出されたすべての誤りを示さなければなりません。 誤り部分符号は誤りの特定の本質について詳しく説明します。
Error checking of an UPDATE message begins by examining the path attributes. If the Withdrawn Routes Length or Total Attribute Length is too large (i.e., if Withdrawn Routes Length + Total Attribute Length + 23 exceeds the message Length), then the Error Subcode MUST be set to Malformed Attribute List.
UPDATEメッセージの誤りの照合は、経路属性を調べることによって、始まります。 Withdrawn Routes LengthかTotal Attribute Lengthが大き過ぎるなら(すなわち、Withdrawn 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 MUST be set to Attribute Flags Error. The Data field MUST contain the erroneous attribute (type, length, and value).
どんな認識された属性にもAttribute Type Codeと衝突するAttribute Flagsがあるなら、Error SubcodeはAttribute Flags Errorに用意ができなければなりません。 Data分野は誤った属性(タイプ、長さ、および値)を含まなければなりません。
Rekhter, et al. Standards Track [Page 32] RFC 4271 BGP-4 January 2006
Rekhter、他 標準化過程[32ページ]RFC4271BGP-2006年1月4日
If any recognized attribute has an Attribute Length that conflicts with the expected length (based on the attribute type code), then the Error Subcode MUST be set to Attribute Length Error. The Data field MUST contain the erroneous attribute (type, length, and value).
どんな認識された属性にも予想された長さ(属性タイプコードに基づいている)と衝突するAttribute Lengthがあるなら、Error SubcodeはAttribute Length Errorに用意ができなければなりません。 Data分野は誤った属性(タイプ、長さ、および値)を含まなければなりません。
If any of the well-known mandatory attributes are not present, then the Error Subcode MUST be set to Missing Well-known Attribute. The Data field MUST contain the Attribute Type Code of the missing, well-known attribute.
よく知られる義務的な属性のいずれも存在していないなら、Error SubcodeはMissing Wellによって知られているAttributeに用意ができなければなりません。 Data分野はなくなって、よく知られる属性のAttribute Type Codeを含まなければなりません。
If any of the well-known mandatory attributes are not recognized, then the Error Subcode MUST be set to Unrecognized Well-known Attribute. The Data field MUST contain the unrecognized attribute (type, length, and value).
よく知られる義務的な属性のいずれも認識されないなら、Error SubcodeはUnrecognized Wellによって知られているAttributeに用意ができなければなりません。 Data分野は認識されていない属性(タイプ、長さ、および値)を含まなければなりません。
If the ORIGIN attribute has an undefined value, then the Error Sub- code MUST be set to Invalid Origin Attribute. The Data field MUST contain the unrecognized attribute (type, length, and value).
未定義値がORIGIN属性にあるなら、Error SubコードをInvalid Origin Attributeに設定しなければなりません。 Data分野は認識されていない属性(タイプ、長さ、および値)を含まなければなりません。
If the NEXT_HOP attribute field is syntactically incorrect, then the Error Subcode MUST be set to Invalid NEXT_HOP Attribute. The Data field MUST contain the incorrect attribute (type, length, and value). Syntactic correctness means that the NEXT_HOP attribute represents a valid IP host address.
ネクスト_HOP属性分野がシンタクス上不正確であるなら、Error SubcodeはInvalidネクスト_HOP Attributeに用意ができなければなりません。 Data分野は不正確な属性(タイプ、長さ、および値)を含まなければなりません。 構文の正当性は、ネクスト_HOP属性が有効なIPホスト・アドレスを表すことを意味します。
The IP address in the NEXT_HOP MUST meet the following criteria to be considered semantically correct:
意味的に正しい状態で考えられて、HOP MUSTが以下の評価基準を満たすネクスト_のIPアドレス:
a) It MUST NOT be the IP address of the receiving speaker.
a) それは受信スピーカーのIPアドレスであるはずがありません。
b) In the case of an EBGP, where the sender and receiver are one
IP hop away from each other, either the IP address in the
NEXT_HOP MUST be the sender's IP address that is used to
establish the BGP connection, or the interface associated with
the NEXT_HOP IP address MUST share a common subnet with the
receiving BGP speaker.
b) EBGPに関するケース、送付者のものがBGP接続を証明するのに使用されるIPアドレスであったなら送付者と受信機が互いから遠くの1つのIPホップ、_ネクストHOP MUSTのどこのIPアドレスであるか、そして、またはネクストに関連しているインタフェースでは、_HOP IPアドレスは受信BGPスピーカーと一般的なサブネットを共有しなければなりません。
If the NEXT_HOP attribute is semantically incorrect, the error SHOULD be logged, and the route SHOULD be ignored. In this case, a NOTIFICATION message SHOULD NOT be sent, and the connection SHOULD NOT be closed.
登録されていてルートSHOULDになってください。HOPが結果と考える_がネクストであるなら意味的に不正確であり、誤りがSHOULDである、無視されます。 送って接続SHOULD NOTになってください。この場合NOTIFICATIONメッセージSHOULD NOT、閉じられます。
The AS_PATH attribute is checked for syntactic correctness. If the path is syntactically incorrect, then the Error Subcode MUST be set to Malformed AS_PATH.
AS_PATH属性は構文の正当性がないかどうかチェックされます。 経路がシンタクス上不正確であるなら、Error SubcodeはMalformed AS_PATHに用意ができなければなりません。
Rekhter, et al. Standards Track [Page 33] RFC 4271 BGP-4 January 2006
Rekhter、他 標準化過程[33ページ]RFC4271BGP-2006年1月4日
If the UPDATE message is received from an external peer, the local system MAY check whether the leftmost (with respect to the position of octets in the protocol message) AS in the AS_PATH attribute is equal to the autonomous system number of the peer that sent the message. If the check determines this is not the case, the Error Subcode MUST be set to Malformed AS_PATH.
外部の同輩からUPDATEメッセージを受け取るなら、ローカルシステムは、AS_PATH属性における一番左(プロトコルメッセージにおける八重奏の位置に関する)のASがメッセージを送った同輩の自律システム番号と等しいかどうかチェックするかもしれません。 チェックが、これがそうでないことを決定するなら、Error SubcodeはMalformed AS_PATHに用意ができなければなりません。
If an optional attribute is recognized, then the value of this attribute MUST be checked. If an error is detected, the attribute MUST be discarded, and the Error Subcode MUST be set to Optional Attribute Error. The Data field MUST contain 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 MUST be 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 MUST be set to Invalid Network Field.
UPDATEメッセージのNLRI分野は構文の正当性がないかどうかチェックされます。 分野がシンタクス上不正確であるなら、Error SubcodeはInvalid Network Fieldに用意ができなければなりません。
If a prefix in the NLRI field is semantically incorrect (e.g., an unexpected multicast IP address), an error SHOULD be logged locally, and the prefix SHOULD be ignored.
SHOULDを前に置いてください。そして、分野がNLRIの接頭語であるなら意味的に不正確であり(例えば、予期していなかったマルチキャストIPアドレス)、誤りがSHOULDである、局所的に登録されてください、無視されます。
An UPDATE message that contains correct path attributes, but no NLRI, SHALL be treated as a valid UPDATE message.
有効なUPDATEメッセージとして扱われた状態で正しい経路属性、NLRIがない、SHALLだけを含むUPDATEメッセージ。
6.4. NOTIFICATION Message Error Handling
6.4. 通知メッセージエラー処理
If a peer sends a NOTIFICATION message, and the receiver of the message detects an error in that message, the receiver cannot use a NOTIFICATION message to report this error back to the peer. Any such error (e.g., 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)SHOULD、も同輩の管理について。 このドキュメントの範囲の外にしかしながら、これをする手段があります。
6.5. Hold Timer Expired Error Handling
6.5. タイマの満期のエラー処理を保持してください。
If a system does not receive successive KEEPALIVE, UPDATE, and/or NOTIFICATION messages within the period specified in the Hold Time field of the OPEN message, then the NOTIFICATION message with the Hold Timer Expired Error Code is sent and the BGP connection is closed.
システムがオープンメッセージのHold Time分野で指定された期間中に連続したKEEPALIVE、UPDATE、そして/または、NOTIFICATIONメッセージを受け取らないなら、Hold Timer Expired Error CodeがあるNOTIFICATIONメッセージを送ります、そして、BGP接続は閉じます。
Rekhter, et al. Standards Track [Page 34] RFC 4271 BGP-4 January 2006
Rekhter、他 標準化過程[34ページ]RFC4271BGP-2006年1月4日
6.6. Finite State Machine Error Handling
6.6. 有限状態機械エラー処理
Any error detected by the BGP Finite State Machine (e.g., receipt of an unexpected event) is indicated by sending the NOTIFICATION message with the Error Code Finite State Machine Error.
BGP Finite州Machine(例えば、予期せぬ出来事の領収書)によって検出されたどんな誤りも、Error Code Finite州Machine Errorと共にNOTIFICATIONメッセージを送ることによって、示されます。
6.7. Cease
6.7. やんでください。
In the 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 the 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メッセージを使用してはいけません。
A BGP speaker MAY support the ability to impose a locally-configured, upper bound on the number of address prefixes the speaker is willing to accept from a neighbor. When the upper bound is reached, the speaker, under control of local configuration, either (a) discards new address prefixes from the neighbor (while maintaining the BGP connection with the neighbor), or (b) terminates the BGP connection with the neighbor. If the BGP speaker decides to terminate its BGP connection with a neighbor because the number of address prefixes received from the neighbor exceeds the locally-configured, upper bound, then the speaker MUST send the neighbor a NOTIFICATION message with the Error Code Cease. The speaker MAY also log this locally.
BGPスピーカーは局所的に構成にされているのでaを課す能力をサポートするかもしれません、スピーカーが隣人から受け入れても構わないと思っているアドレス接頭語の数に関する上限。 上限が達しています、スピーカー、地方の構成で制御されています、(a)が隣人から新しいアドレス接頭語を捨てるか(隣人とのBGP接続を維持している間)、または(b)が隣人とのBGP接続を終えるということであるときに。 隣人から受け取られたアドレス接頭語の数が局所的に構成にされる、上限を超えているのでBGPスピーカーが、隣人とのBGP接続を終えると決めるなら、スピーカーはError Code CeaseがあるNOTIFICATIONメッセージを隣人に送らなければなりません。 また、スピーカーは局所的にこれを登録するかもしれません。
6.8. BGP Connection Collision Detection
6.8. BGP接続衝突検出
If a pair of BGP speakers try to establish a BGP connection with each other simultaneously, then two parallel connections well be formed. If the source IP address used by one of these connections is the same as the destination IP address used by the other, and the destination IP address used by the first connection is the same as the source IP address used by the other, connection collision has occurred. In the event of connection collision, one of the connections MUST be closed.
1組であるなら、スピーカーが試みるBGPでは、互いとの同時のBGP接続、次に2人の並列接続を証明するには、よく形成されてください。 アドレスがこれらの接続のひとりで使用したソースIPがアドレスが最初の接続で使用したもう片方、および目的地IPのそばで中古の送付先IPアドレスがアドレスがもう片方で使用したソースIPと同じであるのと同じであるなら、接続衝突は起こりました。 接続衝突の場合、接続のひとりを閉じなければなりません。
Based on the value of the BGP Identifier, a convention is established for detecting which BGP connection is to be preserved when a collision occurs. 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
オープンメッセージを受け取り次第、ローカルシステムはOpenConfirm状態にある接続のすべてを調べなければなりません。 また、プロトコルの外で同輩について手段でBGP Identifierを知っているなら、BGPスピーカーはOpenSent状態で接続を調べるかもしれません。 これらの接続の中にリモートBGPスピーカーとの接続があれば
Rekhter, et al. Standards Track [Page 35] RFC 4271 BGP-4 January 2006
Rekhter、他 標準化過程[35ページ]RFC4271BGP-2006年1月4日
whose BGP Identifier equals the one in the OPEN message, and this connection collides with the connection over which the OPEN message is received, then the local system performs the following collision resolution procedure:
だれのBGP Identifierはオープンメッセージのものと等しいか、そして、この接続はオープンメッセージが受信されている接続と衝突します、そして、次に、ローカルシステムは以下の衝突解決手順を実行します:
1) The BGP Identifier of the local system is compared to the BGP
Identifier of the remote system (as specified in the OPEN
message). Comparing BGP Identifiers is done by converting them
to host byte order and treating them as 4-octet unsigned
integers.
1) ローカルシステムのBGP IdentifierはリモートシステムのBGP Identifierと比較されます(オープンメッセージで指定されるように)。 BGP Identifiersは、ホストバイトオーダーに彼らを変換して、4八重奏の符号のない整数として彼らを扱うことによって、比較されます。
2) If the value of the local BGP Identifier is less than the
remote one, the local system closes the BGP connection that
already exists (the one that is already in the OpenConfirm
state), and accepts the BGP connection initiated by the remote
system.
2) 地方のBGP Identifierの値がリモートもの以下であるなら、ローカルシステムは、既に存在するBGP接続(OpenConfirm状態に既にあるもの)を終えて、リモートシステムによって開始されたBGP接続を受け入れます。
3) Otherwise, the local system closes the 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状態に既にあるもの)続けています。
Unless allowed via configuration, a connection collision with an existing BGP connection that is in the Established state causes closing of the newly created connection.
構成で許容されていない場合、Established状態にある既存のBGP接続との接続衝突は新たに作成された接続の閉鎖を引き起こします。
Note that a connection collision cannot be detected with connections that are in Idle, Connect, or Active states.
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 at opening a BGP connection, starting with the highest version number each BGP speaker 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 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接続を開くのに複数と同じくらい試みることによって、プロトコルのバージョンを交渉するかもしれません、それぞれのBGPスピーカーがサポートする中で最も大きいバージョン番号から始まって。 開いている試みがError Codeと共に失敗するか、そして、オープンMessage Error、およびError Subcode、UnsupportedバージョンNumber、そして、BGPスピーカーには、有効なそれが試みたバージョン番号、同輩が試みたバージョン番号、NOTIFICATIONメッセージの同輩によって通過されたバージョン番号、およびそれがサポートするバージョン番号があります。 2人の同輩が1つ以上の一般的なバージョンをサポートすると、これで、彼らは急速に最も高い一般的なバージョンを決定できるでしょう。 BGPがバージョン交渉であるとサポートするために、BGP MUSTの将来のバージョンはオープンとNOTIFICATIONメッセージの形式を保有します。
Rekhter, et al. Standards Track [Page 36] RFC 4271 BGP-4 January 2006
Rekhter、他 標準化過程[36ページ]RFC4271BGP-2006年1月4日
8. BGP Finite State Machine (FSM)
8. BGP有限状態機械(FSM)
The data structures and FSM described in this document are conceptual and do not have to be implemented precisely as described here, as long as the implementations support the described functionality and they exhibit the same externally visible behavior.
本書では説明されたデータ構造とFSMは概念的であり、まさにここで説明されるように実装される必要はありません、実装が説明された機能性をサポートして、同じ外部的に目に見える振舞いを示す限り。
This section specifies the BGP operation in terms of a Finite State Machine (FSM). The section falls into two parts:
このセクションはFinite州Machine(FSM)に関してBGP操作を指定します。 セクションは2つの部品になります:
1) Description of Events for the State machine (Section 8.1)
2) Description of the FSM (Section 8.2)
1) 州マシン(セクション8.1)のためのEventsの記述 2) FSMの記述(セクション8.2)
Session attributes required (mandatory) for each connection are:
各接続に必要である(義務的な)セッション属性は以下の通りです。
1) State
2) ConnectRetryCounter
3) ConnectRetryTimer
4) ConnectRetryTime
5) HoldTimer
6) HoldTime
7) KeepaliveTimer
8) KeepaliveTime
1) 状態2) ConnectRetryCounter3) ConnectRetryTimer4) ConnectRetryTime5) HoldTimer6) HoldTime7) KeepaliveTimer8) KeepaliveTime
The state session attribute indicates the current state of the BGP FSM. The ConnectRetryCounter indicates the number of times a BGP peer has tried to establish a peer session.
州のセッション属性はBGP FSMの現状を示します。 ConnectRetryCounterはBGP同輩が同輩セッションを確立しようとしたという回の数を示します。
The mandatory attributes related to timers are described in Section 10. Each timer has a "timer" and a "time" (the initial value).
タイマに関連する義務的な属性はセクション10で説明されます。 各タイマには、「タイマ」と「時間」(初期の値)があります。
The optional Session attributes are listed below. These optional attributes may be supported, either per connection or per local system:
任意のSession属性は以下に記載されています。 これらの任意の属性は接続かローカルシステム単位でサポートされるかもしれません:
1) AcceptConnectionsUnconfiguredPeers
2) AllowAutomaticStart
3) AllowAutomaticStop
4) CollisionDetectEstablishedState
5) DampPeerOscillations
6) DelayOpen
7) DelayOpenTime
8) DelayOpenTimer
9) IdleHoldTime
10) IdleHoldTimer
11) PassiveTcpEstablishment
12) SendNOTIFICATIONwithoutOPEN
13) TrackTcpState
1) AcceptConnectionsUnconfiguredPeers2) AllowAutomaticStart3) AllowAutomaticStop4) CollisionDetectEstablishedState5) DampPeerOscillations6) DelayOpen7) DelayOpenTime8) DelayOpenTimer9) IdleHoldTime10) IdleHoldTimer11) PassiveTcpEstablishment12) SendNOTIFICATIONwithoutOPEN13) TrackTcpState
Rekhter, et al. Standards Track [Page 37] RFC 4271 BGP-4 January 2006
Rekhter、他 標準化過程[37ページ]RFC4271BGP-2006年1月4日
The optional session attributes support different features of the BGP functionality that have implications for the BGP FSM state transitions. Two groups of the attributes which relate to timers are:
任意のセッション属性はBGP FSM状態遷移のために意味を持っているBGPの機能性の異なった特徴をサポートします。 タイマに関連する属性の2つのグループは以下の通りです。
group 1: DelayOpen, DelayOpenTime, DelayOpenTimer
group 2: DampPeerOscillations, IdleHoldTime, IdleHoldTimer
グループ1: DelayOpen、DelayOpenTime、DelayOpenTimerグループ2: DampPeerOscillations、IdleHoldTime、IdleHoldTimer
The first parameter (DelayOpen, DampPeerOscillations) is an optional attribute that indicates that the Timer function is active. The "Time" value specifies the initial value for the "Timer" (DelayOpenTime, IdleHoldTime). The "Timer" specifies the actual timer.
最初のパラメタ(DelayOpen、DampPeerOscillations)はTimer機能がアクティブであることを示す任意の属性です。 「時間」値は「タイマ」(DelayOpenTime、IdleHoldTime)に初期の値を指定します。 「タイマ」は実際のタイマを指定します。
Please refer to Section 8.1.1 for an explanation of the interaction between these optional attributes and the events signaled to the state machine. Section 8.2.1.3 also provides a short overview of the different types of optional attributes (flags or timers).
州のマシンに合図されたこれらの任意の属性とイベントとの相互作用に関する説明についてセクション8.1.1を参照してください。 セクション8.2 .1 .3 また、異なったタイプの任意の属性(旗かタイマ)の短い概要を提供します。
8.1. Events for the BGP FSM
8.1. BGP FSMのためのイベント
8.1.1. Optional Events Linked to Optional Session Attributes
8.1.1. 任意のセッション属性にリンクされた任意のイベント
The Inputs to the BGP FSM are events. Events can either be mandatory or optional. Some optional events are linked to optional session attributes. Optional session attributes enable several groups of FSM functionality.
BGP FSMへのInputsはイベントです。 イベントは、義務的であるか、または任意である場合があります。 いくつかの任意のイベントが任意のセッション属性にリンクされます。 任意のセッション属性はFSMの機能性のいくつかのグループを可能にします。
The linkage between FSM functionality, events, and the optional session attributes are described below.
FSMの機能性と、イベントと、属性が説明される任意のセッションの間のリンケージ。
Group 1: Automatic Administrative Events (Start/Stop)
グループ1: 自動管理イベント(始め/停止)
Optional Session Attributes: AllowAutomaticStart,
AllowAutomaticStop,
DampPeerOscillations,
IdleHoldTime, IdleHoldTimer
任意のセッション属性: AllowAutomaticStart、AllowAutomaticStop、DampPeerOscillations、IdleHoldTime、IdleHoldTimer
Option 1: AllowAutomaticStart
オプション1: AllowAutomaticStart
Description: A BGP peer connection can be started and stopped
by administrative control. This administrative
control can either be manual, based on operator
intervention, or under the control of logic that
is specific to a BGP implementation. The term
"automatic" refers to a start being issued to the
BGP peer connection FSM when such logic determines
that the BGP peer connection should be restarted.
記述: 運営管理コントロールでBGP同輩接続を始めて、止めることができます。 この運営管理コントロールはオペレータ介入に基づいたBGP実装に特定の論理のコントロールの下で手動である場合があります。 「自動である」という用語はそのような論理が、BGP同輩接続が再出発されるべきであることを決定するとBGP同輩接続FSMに発行される始めについて言及します。
Rekhter, et al. Standards Track [Page 38] RFC 4271 BGP-4 January 2006
Rekhter、他 標準化過程[38ページ]RFC4271BGP-2006年1月4日
The AllowAutomaticStart attribute specifies that
this BGP connection supports automatic starting of
the BGP connection.
AllowAutomaticStart属性は、このBGP接続がBGP接続の自動始めをサポートすると指定します。
If the BGP implementation supports
AllowAutomaticStart, the peer may be repeatedly
restarted. Three other options control the rate
at which the automatic restart occurs:
DampPeerOscillations, IdleHoldTime, and the
IdleHoldTimer.
BGP実装がAllowAutomaticStartをサポートするなら、同輩は繰り返して再出発されるかもしれません。 3つの別の選択肢が自動再始動が起こる速度を制御します: DampPeerOscillations、IdleHoldTime、およびIdleHoldTimer。
The DampPeerOscillations option specifies that the
implementation engages additional logic to damp
the oscillations of BGP peers in the face of
sequences of automatic start and automatic stop.
IdleHoldTime specifies the length of time the BGP
peer is held in the Idle state prior to allowing
the next automatic restart. The IdleHoldTimer is
the timer that holds the peer in Idle state.
DampPeerOscillationsオプションは、実装が自動起動と自動停止の系列に直面してBGP同輩の振動をじめじめとするように追加論理を従事させると指定します。 IdleHoldTimeは次の自動再始動を許容する前にBGP同輩がIdle状態で開催される時の長さを指定します。 IdleHoldTimerはIdle状態で同輩を支えるタイマです。
An example of DampPeerOscillations logic is an
increase of the IdleHoldTime value if a BGP peer
oscillates connectivity (connected/disconnected)
repeatedly within a time period. To engage this
logic, a peer could connect and disconnect 10
times within 5 minutes. The IdleHoldTime value
would be reset from 0 to 120 seconds.
BGP同輩が振動するならDampPeerOscillations論理に関する例がIdleHoldTime価値の増加である、接続性(接続されるか、または切断される)、反復、期間以内に。 同輩は、5分以内にこの論理を従事させるために、10回接続して、切断することができました。 IdleHoldTime値は0〜120秒リセットされるでしょう。
Values: TRUE or FALSE
値: 本当であるか、または誤っています。
Option 2: AllowAutomaticStop
オプション2: AllowAutomaticStop
Description: This BGP peer session optional attribute indicates
that the BGP connection allows "automatic"
stopping of the BGP connection. An "automatic"
stop is defined as a stop under the control of
implementation-specific logic. The
implementation-specific logic is outside the scope
of this specification.
記述: このBGP同輩セッションのときに、任意の属性は、BGP接続がBGP接続の「自動である」停止を許すのを示します。 「自動である」停止は実装特有の論理のコントロールの下の停止と定義されます。 この仕様の範囲の外に実装特有の論理があります。
Values: TRUE or FALSE
値: 本当であるか、または誤っています。
Option 3: DampPeerOscillations
オプション3: DampPeerOscillations
Description: The DampPeerOscillations optional session
attribute indicates that the BGP connection is
using logic that damps BGP peer oscillations in
the Idle State.
記述: DampPeerOscillationsの任意のセッション属性は、BGP接続がIdle州でBGP同輩振動をじめじめとする論理を使用しているのを示します。
Rekhter, et al. Standards Track [Page 39] RFC 4271 BGP-4 January 2006
Rekhter、他 標準化過程[39ページ]RFC4271BGP-2006年1月4日
Value: TRUE or FALSE
値: 本当であるか、または誤っています。
Option 4: IdleHoldTime
オプション4: IdleHoldTime
Description: The IdleHoldTime is the value that is set in the
IdleHoldTimer.
記述: IdleHoldTimeはIdleHoldTimerに設定される値です。
Values: Time in seconds
値: 秒の時間
Option 5: IdleHoldTimer
オプション5: IdleHoldTimer
Description: The IdleHoldTimer aids in controlling BGP peer
oscillation. The IdleHoldTimer is used to keep
the BGP peer in Idle for a particular duration.
The IdleHoldTimer_Expires event is described in
Section 8.1.3.
記述: IdleHoldTimerはBGP同輩振動を制御する際に支援します。 IdleHoldTimerは、特定の持続時間のためにIdleにBGP同輩をおくのに使用されます。 IdleHoldTimer_Expiresイベントはセクション8.1.3で説明されます。
Values: Time in seconds
値: 秒の時間
Group 2: Unconfigured Peers
グループ2: 同輩をUnconfiguredしました。
Optional Session Attributes: AcceptConnectionsUnconfiguredPeers
任意のセッション属性: AcceptConnectionsUnconfiguredPeers
Option 1: AcceptConnectionsUnconfiguredPeers
オプション1: AcceptConnectionsUnconfiguredPeers
Description: The BGP FSM optionally allows the acceptance of
BGP peer connections from neighbors that are not
pre-configured. The
"AcceptConnectionsUnconfiguredPeers" optional
session attribute allows the FSM to support the
state transitions that allow the implementation to
accept or reject these unconfigured peers.
記述: BGP FSMはあらかじめ設定されない隣人からBGP同輩接続の承認を任意に許容します。 「AcceptConnectionsUnconfiguredPeers」任意のセッション属性で、FSMは、状態が実装がこれらの非構成された同輩を受け入れるか、または拒絶する変遷であると、サポートすることができます。
The AcceptConnectionsUnconfiguredPeers has
security implications. Please refer to the BGP
Vulnerabilities document [RFC4272] for details.
AcceptConnectionsUnconfiguredPeersには、セキュリティ意味があります。 詳細についてBGP Vulnerabilitiesドキュメント[RFC4272]を参照してください。
Value: True or False
値: 本当であるか、または誤っています。
Group 3: TCP processing
グループ3: TCP処理
Optional Session Attributes: PassiveTcpEstablishment,
TrackTcpState
任意のセッション属性: PassiveTcpEstablishment、TrackTcpState
Option 1: PassiveTcpEstablishment
オプション1: PassiveTcpEstablishment
Rekhter, et al. Standards Track [Page 40] RFC 4271 BGP-4 January 2006
Rekhter、他 標準化過程[40ページ]RFC4271BGP-2006年1月4日
Description: This option indicates that the BGP FSM will
passively wait for the remote BGP peer to
establish the BGP TCP connection.
記述: このオプションは、BGP FSMが、リモートBGP同輩がBGP TCP接続を確立するのを受け身に待つのを示します。
value: TRUE or FALSE
値: 本当であるか、または誤っています。
Option 2: TrackTcpState
オプション2: TrackTcpState
Description: The BGP FSM normally tracks the end result of a
TCP connection attempt rather than individual TCP
messages. Optionally, the BGP FSM can support
additional interaction with the TCP connection
negotiation. The interaction with the TCP events
may increase the amount of logging the BGP peer
connection requires and the number of BGP FSM
changes.
記述: 通常、BGP FSMは個々のTCPメッセージよりむしろTCP接続試みの結末を追跡します。 任意に、BGP FSMはTCP接続交渉との追加相互作用をサポートすることができます。 TCPイベントとの相互作用はBGP同輩接続が必要とする伐採の量とBGP FSM変化の数を増強するかもしれません。
Value: TRUE or FALSE
値: 本当であるか、または誤っています。
Group 4: BGP Message Processing
グループ4: BGPメッセージ処理
Optional Session Attributes: DelayOpen, DelayOpenTime,
DelayOpenTimer,
SendNOTIFICATIONwithoutOPEN,
CollisionDetectEstablishedState
任意のセッション属性: DelayOpen、DelayOpenTime、DelayOpenTimer、SendNOTIFICATIONwithoutOPEN、CollisionDetectEstablishedState
Option 1: DelayOpen
オプション1: DelayOpen
Description: The DelayOpen optional session attribute allows
implementations to be configured to delay sending
an OPEN message for a specific time period
(DelayOpenTime). The delay allows the remote BGP
Peer time to send the first OPEN message.
記述: DelayOpenの任意のセッション属性は、実装が特定の期間(DelayOpenTime)へのオープンメッセージを送るのを遅らせるために構成されるのを許容します。 遅れは最初のオープンメッセージを送る時間をリモートBGP Peerに許容します。
Value: TRUE or FALSE
値: 本当であるか、または誤っています。
Option 2: DelayOpenTime
オプション2: DelayOpenTime
Description: The DelayOpenTime is the initial value set in the
DelayOpenTimer.
記述: DelayOpenTimeはDelayOpenTimerの初期の選択値群です。
Value: Time in seconds
値: 秒の時間
Option 3: DelayOpenTimer
オプション3: DelayOpenTimer
Description: The DelayOpenTimer optional session attribute is
used to delay the sending of an OPEN message on a
記述: DelayOpenTimerの任意のセッション属性は、aでのオープンメッセージの発信を遅らせるのに使用されます。
Rekhter, et al. Standards Track [Page 41] RFC 4271 BGP-4 January 2006
Rekhter、他 標準化過程[41ページ]RFC4271BGP-2006年1月4日
connection. The DelayOpenTimer_Expires event
(Event 12) is described in Section 8.1.3.
接続。 DelayOpenTimer_Expiresイベント(イベント12)はセクション8.1.3で説明されます。
Value: Time in seconds
値: 秒の時間
Option 4: SendNOTIFICATIONwithoutOPEN
オプション4: SendNOTIFICATIONwithoutOPEN
Description: The SendNOTIFICATIONwithoutOPEN allows a peer to
send a NOTIFICATION without first sending an OPEN
message. Without this optional session attribute,
the BGP connection assumes that an OPEN message
must be sent by a peer prior to the peer sending a
NOTIFICATION message.
記述: 最初にオープンメッセージを送らないで、SendNOTIFICATIONwithoutOPENは同輩を通知書を送らせます。 この任意のセッション属性がなければ、BGP接続は、同輩がNOTIFICATIONメッセージを送る同輩の前にオープンメッセージを送らなければならないと仮定します。
Value: True or False
値: 本当であるか、または誤っています。
Option 5: CollisionDetectEstablishedState
オプション5: CollisionDetectEstablishedState
Description: Normally, a Detect Collision (see Section 6.8)
will be ignored in the Established state. This
optional session attribute indicates that this BGP
connection processes collisions in the Established
state.
記述: 通常、Detect Collision(セクション6.8を見る)はEstablished状態で無視されるでしょう。 この任意のセッション属性は、このBGP接続がEstablished状態で衝突を処理するのを示します。
Value: True or False
値: 本当であるか、または誤っています。
Note: The optional session attributes clarify the BGP FSM
description for existing features of BGP implementations.
The optional session attributes may be pre-defined for an
implementation and not readable via management interfaces
for existing correct implementations. As newer BGP MIBs
(version 2 and beyond) are supported, these fields will be
accessible via a management interface.
以下に注意してください。 任意のセッション属性はBGP実装の既存の特徴のためのBGP FSM記述をはっきりさせます。 既存の正しい実装には、任意のセッション属性は、実装のために事前に定義されていて管理インタフェースを通して読み込み可能でないかもしれません。 より新しいBGP MIBs(バージョン2と以遠)がサポートされるとき、これらの分野は管理インタフェースを通してアクセスしやすくなるでしょう。
8.1.2. Administrative Events
8.1.2. 管理イベント
An administrative event is an event in which the operator interface and BGP Policy engine signal the BGP-finite state machine to start or stop the BGP state machine. The basic start and stop indications are augmented by optional connection attributes that signal a certain type of start or stop mechanism to the BGP FSM. An example of this combination is Event 5, AutomaticStart_with_PassiveTcpEstablishment. With this event, the BGP implementation signals to the BGP FSM that the implementation is using an Automatic Start with the option to use a Passive TCP Establishment. The Passive TCP establishment signals that this BGP FSM will wait for the remote side to start the TCP establishment.
管理イベントはオペレータ・インタフェースとBGP Policyエンジンが始まるか、またはBGP州のマシンを止めるようにBGP-有限状態機械に合図するイベントです。 基本的な始めと停止指摘はあるタイプの始まりを示すか、またはBGP FSMにメカニズムを止める任意の接続属性によって増大させられます。 この組み合わせに関する例はEvent5、_PassiveTcpEstablishmentとAutomaticStart_です。 このイベントで、BGP実装は、実装がPassive TCP特権階級を使用するのにオプションがあるAutomatic Startを使用しているのをBGP FSMに示します。 Passive TCP設立は、このBGP FSMが、遠隔地側がTCP設立を始めるのを待つのを示します。
Rekhter, et al. Standards Track [Page 42] RFC 4271 BGP-4 January 2006
Rekhter、他 標準化過程[42ページ]RFC4271BGP-2006年1月4日
Note that only Event 1 (ManualStart) and Event 2 (ManualStop) are mandatory administrative events. All other administrative events are optional (Events 3-8). Each event below has a name, definition, status (mandatory or optional), and the optional session attributes that SHOULD be set at each stage. When generating Event 1 through Event 8 for the BGP FSM, the conditions specified in the "Optional Attribute Status" section are verified. If any of these conditions are not satisfied, then the local system should log an FSM error.
Event1(ManualStart)と唯一のEvent2(ManualStop)が義務的な管理イベントであることに注意してください。 他のすべての管理イベントが任意です(イベント3-8)。 以下の各イベントには、名前があります、定義、状態(義務的であるか任意の)、そして、SHOULDをある任意のセッション属性は各段階でセットしました。 BGP FSMのためにEvent8を通してEvent1を生成するとき、「任意の属性状態」セクションで指定された状態は確かめられます。 これらの状態のいずれも満たされていないなら、ローカルシステムはFSM誤りを登録するべきです。
The settings of optional session attributes may be implicit in some implementations, and therefore may not be set explicitly by an external operator action. Section 8.2.1.5 describes these implicit settings of the optional session attributes. The administrative states described below may also be implicit in some implementations and not directly configurable by an external operator.
任意のセッション属性の設定は、いくつかの実装で暗黙であるかもしれなく、したがって、外部のオペレータ動きで明らかに設定されないかもしれません。 セクション8.2 .1 .5 任意のセッション属性のこれらの内在している設定について説明します。 また、以下で説明された管理州も、いくつかの実装で暗黙であって外部のオペレータは直接構成可能でないかもしれません。
Event 1: ManualStart
イベント1: ManualStart
Definition: Local system administrator manually starts the peer
connection.
定義: ローカルシステム管理者は手動で同輩接続を始めます。
Status: Mandatory
状態: 義務的
Optional
Attribute
Status: The PassiveTcpEstablishment attribute SHOULD be set
to FALSE.
任意の属性状態: PassiveTcpEstablishmentはSHOULDを結果と考えます。FALSEに、用意ができています。
Event 2: ManualStop
イベント2: ManualStop
Definition: Local system administrator manually stops the peer
connection.
定義: ローカルシステム管理者は手動で同輩接続を止めます。
Status: Mandatory
状態: 義務的
Optional
Attribute
Status: No interaction with any optional attributes.
任意の属性状態: どんな任意の属性との相互作用がありません。
Event 3: AutomaticStart
イベント3: AutomaticStart
Definition: Local system automatically starts the BGP
connection.
定義: ローカルシステムは自動的にBGP接続を始めます。
Status: Optional, depending on local system
状態: 任意である、ローカルシステムによること。
Rekhter, et al. Standards Track [Page 43] RFC 4271 BGP-4 January 2006
Rekhter、他 標準化過程[43ページ]RFC4271BGP-2006年1月4日
Optional
Attribute
Status: 1) The AllowAutomaticStart attribute SHOULD be set
to TRUE if this event occurs.
2) If the PassiveTcpEstablishment optional session
attribute is supported, it SHOULD be set to
FALSE.
3) If the DampPeerOscillations is supported, it
SHOULD be set to FALSE when this event occurs.
任意の属性状態: 1) AllowAutomaticStartはSHOULDを結果と考えます。TRUEに、このイベントが起こるなら、用意ができています。 2) 属性はPassiveTcpEstablishment任意のセッションであるならサポートされて、それはSHOULDです。FALSEに設定されます。 3) DampPeerOscillationsはサポートされて、それはSHOULDです。このイベントが起こるFALSEに設定されてください。
Event 4: ManualStart_with_PassiveTcpEstablishment
イベント4: _PassiveTcpEstablishmentとManualStart_
Definition: Local system administrator manually starts the peer
connection, but has PassiveTcpEstablishment
enabled. The PassiveTcpEstablishment optional
attribute indicates that the peer will listen prior
to establishing the connection.
定義: ローカルシステム管理者は、手動で同輩接続を始めますが、PassiveTcpEstablishmentを有効にさせます。 PassiveTcpEstablishmentの任意の属性は、接続を確立する前に同輩が聴くのを示します。
Status: Optional, depending on local system
状態: 任意である、ローカルシステムによること。
Optional
Attribute
Status: 1) The PassiveTcpEstablishment attribute SHOULD be
set to TRUE if this event occurs.
2) The DampPeerOscillations attribute SHOULD be set
to FALSE when this event occurs.
任意の属性状態: 1) PassiveTcpEstablishmentはSHOULDを結果と考えます。TRUEに、このイベントが起こるなら、用意ができています。 2) FALSEへのセットがいつであったかときに、DampPeerOscillationsはSHOULDを結果と考えます。このイベントは起こります。
Event 5: AutomaticStart_with_PassiveTcpEstablishment
イベント5: _PassiveTcpEstablishmentとAutomaticStart_
Definition: Local system automatically starts the BGP
connection with the PassiveTcpEstablishment
enabled. The PassiveTcpEstablishment optional
attribute indicates that the peer will listen prior
to establishing a connection.
定義: ローカルシステムは自動的に有効にされるPassiveTcpEstablishmentとのBGP接続を始めます。 PassiveTcpEstablishmentの任意の属性は、同輩が取引関係を築く前に聴くのを示します。
Status: Optional, depending on local system
状態: 任意である、ローカルシステムによること。
Optional
Attribute
Status: 1) The AllowAutomaticStart attribute SHOULD be set
to TRUE.
2) The PassiveTcpEstablishment attribute SHOULD be
set to TRUE.
3) If the DampPeerOscillations attribute is
supported, the DampPeerOscillations SHOULD be
set to FALSE.
任意の属性状態: 1) AllowAutomaticStartはSHOULDを結果と考えます。TRUEに、用意ができています。 2) PassiveTcpEstablishmentはSHOULDを結果と考えます。TRUEに、用意ができています。 3) DampPeerOscillations属性がサポートされるならDampPeerOscillations SHOULD、FALSEに設定されてください。
Rekhter, et al. Standards Track [Page 44] RFC 4271 BGP-4 January 2006
Rekhter、他 標準化過程[44ページ]RFC4271BGP-2006年1月4日
Event 6: AutomaticStart_with_DampPeerOscillations
イベント6: _DampPeerOscillationsとAutomaticStart_
Definition: Local system automatically starts the BGP peer
connection with peer oscillation damping enabled.
The exact method of damping persistent peer
oscillations is determined by the implementation
and is outside the scope of this document.
定義: ローカルシステムは自動的に可能にされる同輩振動湿気とのBGP同輩接続を始めます。 永続的な同輩振動をじめじめとする正確なメソッドは、実装で決定して、このドキュメントの範囲の外にあります。
Status: Optional, depending on local system.
状態: 任意である、ローカルシステムによります。
Optional
Attribute
Status: 1) The AllowAutomaticStart attribute SHOULD be set
to TRUE.
2) The DampPeerOscillations attribute SHOULD be set
to TRUE.
3) The PassiveTcpEstablishment attribute SHOULD be
set to FALSE.
任意の属性状態: 1) AllowAutomaticStartはSHOULDを結果と考えます。TRUEに、用意ができています。 2) DampPeerOscillationsはSHOULDを結果と考えます。TRUEに、用意ができています。 3) PassiveTcpEstablishmentはSHOULDを結果と考えます。FALSEに、用意ができています。
Event 7: AutomaticStart_with_DampPeerOscillations_and_
PassiveTcpEstablishment
イベント7: _DampPeerOscillations_と_PassiveTcpEstablishmentとAutomaticStart_
Definition: Local system automatically starts the BGP peer
connection with peer oscillation damping enabled
and PassiveTcpEstablishment enabled. The exact
method of damping persistent peer oscillations is
determined by the implementation and is outside the
scope of this document.
定義: ローカルシステムは自動的に可能にされる同輩振動湿気と有効にされるPassiveTcpEstablishmentとのBGP同輩接続を始めます。 永続的な同輩振動をじめじめとする正確なメソッドは、実装で決定して、このドキュメントの範囲の外にあります。
Status: Optional, depending on local system
状態: 任意である、ローカルシステムによること。
Optional
Attributes
Status: 1) The AllowAutomaticStart attribute SHOULD be set
to TRUE.
2) The DampPeerOscillations attribute SHOULD be set
to TRUE.
3) The PassiveTcpEstablishment attribute SHOULD be
set to TRUE.
任意の属性状態: 1) AllowAutomaticStartはSHOULDを結果と考えます。TRUEに、用意ができています。 2) DampPeerOscillationsはSHOULDを結果と考えます。TRUEに、用意ができています。 3) PassiveTcpEstablishmentはSHOULDを結果と考えます。TRUEに、用意ができています。
Event 8: AutomaticStop
イベント8: AutomaticStop
Definition: Local system automatically stops the BGP
connection.
定義: ローカルシステムは自動的にBGP接続を止めます。
An example of an automatic stop event is exceeding
the number of prefixes for a given peer and the
local system automatically disconnecting the peer.
自動停止イベントに関する例は与えられた同輩とローカルシステムのために自動的に接頭語の数を超えています同輩が切断する。
Rekhter, et al. Standards Track [Page 45] RFC 4271 BGP-4 January 2006
Rekhter、他 標準化過程[45ページ]RFC4271BGP-2006年1月4日
Status: Optional, depending on local system
状態: 任意である、ローカルシステムによること。
Optional
Attribute
Status: 1) The AllowAutomaticStop attribute SHOULD be TRUE.
任意の属性状態: 1) AllowAutomaticStopはSHOULDを結果と考えます。TRUEになってください。
8.1.3. Timer Events
8.1.3. タイマイベント
Event 9: ConnectRetryTimer_Expires
イベント9: ConnectRetryTimer_は期限が切れます。
Definition: An event generated when the ConnectRetryTimer
expires.
定義: ConnectRetryTimerが期限が切れるとき生成されたイベント。
Status: Mandatory
状態: 義務的
Event 10: HoldTimer_Expires
イベント10: HoldTimer_は期限が切れます。
Definition: An event generated when the HoldTimer expires.
定義: HoldTimerが期限が切れるとき生成されたイベント。
Status: Mandatory
状態: 義務的
Event 11: KeepaliveTimer_Expires
イベント11: KeepaliveTimer_は期限が切れます。
Definition: An event generated when the KeepaliveTimer expires.
定義: KeepaliveTimerが期限が切れるとき生成されたイベント。
Status: Mandatory
状態: 義務的
Event 12: DelayOpenTimer_Expires
イベント12: DelayOpenTimer_は期限が切れます。
Definition: An event generated when the DelayOpenTimer expires.
定義: DelayOpenTimerが期限が切れるとき生成されたイベント。
Status: Optional
状態: 任意
Optional
Attribute
Status: If this event occurs,
1) DelayOpen attribute SHOULD be set to TRUE,
2) DelayOpenTime attribute SHOULD be supported,
3) DelayOpenTimer SHOULD be supported.
任意の属性状態: このイベントが起こるなら1) DelayOpenがSHOULDを結果と考える、TRUE、2に)設定されてください。 DelayOpenTimeがSHOULDを結果と考える、サポートされてください、3) DelayOpenTimer SHOULD、サポートされてください。
Event 13: IdleHoldTimer_Expires
イベント13: IdleHoldTimer_は期限が切れます。
Definition: An event generated when the IdleHoldTimer expires,
indicating that the BGP connection has completed
waiting for the back-off period to prevent BGP peer
oscillation.
定義: IdleHoldTimerであるときに生成されたイベントは期限が切れます、BGP接続が、下に後部の期間、BGP同輩振動を防ぐのを待つのを完了したのを示して。
Rekhter, et al. Standards Track [Page 46] RFC 4271 BGP-4 January 2006
Rekhter、他 標準化過程[46ページ]RFC4271BGP-2006年1月4日
The IdleHoldTimer is only used when the persistent
peer oscillation damping function is enabled by
setting the DampPeerOscillations optional attribute
to TRUE.
永続的な同輩振動湿気機能がDampPeerOscillationsの任意の属性をTRUEに設定することによって可能にされるときだけ、IdleHoldTimerは使用されます。
Implementations not implementing the persistent
peer oscillation damping function may not have the
IdleHoldTimer.
永続的な同輩振動湿気機能を実装しない実装はIdleHoldTimerを持っていないかもしれません。
Status: Optional
状態: 任意
Optional
Attribute
Status: If this event occurs:
1) DampPeerOscillations attribute SHOULD be set to
TRUE.
2) IdleHoldTimer SHOULD have just expired.
任意の属性状態: このイベントが起こるなら: 1) DampPeerOscillationsはSHOULDを結果と考えます。TRUEに、用意ができています。 2) IdleHoldTimer SHOULDはちょうど期限が切れたところです。
8.1.4. TCP Connection-Based Events
8.1.4. TCPの接続ベースのイベント
Event 14: TcpConnection_Valid
イベント14: TcpConnection_有効です。
Definition: Event indicating the local system reception of a
TCP connection request with a valid source IP
address, TCP port, destination IP address, and TCP
Port. The definition of invalid source and invalid
destination IP address is determined by the
implementation.
定義: 有効なソースIPアドレスでTCP接続要求のローカルシステムレセプションを示すイベント、TCPポート、送付先IPアドレス、およびTCP Port。 無効のソースと無効の送付先IPアドレスの定義は実装で決定します。
BGP's destination port SHOULD be port 179, as
defined by IANA.
IANAによって定義されるようにBGPの目的地はポートが179であったならSHOULDを移植します。
TCP connection request is denoted by the local
system receiving a TCP SYN.
TCP接続要求はTCP SYNを受けるローカルシステムによって指示されます。
Status: Optional
状態: 任意
Optional
Attribute
Status: 1) The TrackTcpState attribute SHOULD be set to
TRUE if this event occurs.
任意の属性状態: 1) TrackTcpStateはSHOULDを結果と考えます。TRUEに、このイベントが起こるなら、用意ができています。
Event 15: Tcp_CR_Invalid
イベント15: Tcp_CR_病人
Definition: Event indicating the local system reception of a
TCP connection request with either an invalid
source address or port number, or an invalid
destination address or port number.
定義: 無効のソースアドレスかポートナンバーか無効の送付先アドレスかポートナンバーのどちらかでTCP接続要求のローカルシステムレセプションを示すイベント。
Rekhter, et al. Standards Track [Page 47] RFC 4271 BGP-4 January 2006
Rekhter、他 標準化過程[47ページ]RFC4271BGP-2006年1月4日
BGP destination port number SHOULD be 179, as
defined by IANA.
BGPの目的地は数のSHOULDを移植します。IANAによって定義されるように179になってください。
A TCP connection request occurs when the local
system receives a TCP SYN.
ローカルシステムがTCP SYNを受けるとき、TCP接続要求は現れます。
Status: Optional
状態: 任意
Optional
Attribute
Status: 1) The TrackTcpState attribute should be set to
TRUE if this event occurs.
任意の属性状態: 1) このイベントが起こるなら、TrackTcpState属性はTRUEに設定されるべきです。
Event 16: Tcp_CR_Acked
イベント16: Tcp_CR_Acked
Definition: Event indicating the local system's request to
establish a TCP connection to the remote peer.
定義: TCP接続をリモート同輩に確立するというローカルシステムの要求を示すイベント。
The local system's TCP connection sent a TCP SYN,
received a TCP SYN/ACK message, and sent a TCP ACK.
ローカルシステムのTCP接続は、TCP SYNを送って、TCP SYN/ACKメッセージを受け取って、TCP ACKを送りました。
Status: Mandatory
状態: 義務的
Event 17: TcpConnectionConfirmed
イベント17: TcpConnectionConfirmed
Definition: Event indicating that the local system has received
a confirmation that the TCP connection has been
established by the remote site.
定義: ローカルシステムがリモートサイトのそばに確立していた状態でTCP接続がそうである確認を受け取ったのを示すイベント。
The remote peer's TCP engine sent a TCP SYN. The
local peer's TCP engine sent a SYN, ACK message and
now has received a final ACK.
リモート同輩のTCPエンジンはTCP SYNを送りました。 地元の同輩のTCPエンジンは、SYN、ACKメッセージを送って、現在、最終的なACKを受けました。
Status: Mandatory
状態: 義務的
Event 18: TcpConnectionFails
イベント18: TcpConnectionFails
Definition: Event indicating that the local system has received
a TCP connection failure notice.
定義: ローカルシステムがTCP接続失敗通知を受け取ったのを示すイベント。
The remote BGP peer's TCP machine could have sent a
FIN. The local peer would respond with a FIN-ACK.
Another possibility is that the local peer
indicated a timeout in the TCP connection and
downed the connection.
リモートBGP同輩のTCPマシンはFINを送ったかもしれません。 地元の同輩はFIN-ACKと共に応じるでしょう。 別の可能性は地元の同輩がTCP接続におけるタイムアウトを示して、接続より倒したということです。
Status: Mandatory
状態: 義務的
Rekhter, et al. Standards Track [Page 48] RFC 4271 BGP-4 January 2006
Rekhter、他 標準化過程[48ページ]RFC4271BGP-2006年1月4日
8.1.5. BGP Message-Based Events
8.1.5. BGPのメッセージベースのイベント
Event 19: BGPOpen
イベント19: BGPOpen
Definition: An event is generated when a valid OPEN message has
been received.
定義: 有効なオープンメッセージを受け取ったとき、イベントは発生しています。
Status: Mandatory
状態: 義務的
Optional
Attribute
Status: 1) The DelayOpen optional attribute SHOULD be set
to FALSE.
2) The DelayOpenTimer SHOULD not be running.
任意の属性状態: 1) SHOULDを結果と考えてください。DelayOpen任意である、FALSEに、用意ができています。 2) DelayOpenTimer SHOULD、稼働していません。
Event 20: BGPOpen with DelayOpenTimer running
イベント20: DelayOpenTimerが稼働であっている中のBGPOpen
Definition: An event is generated when a valid OPEN message has
been received for a peer that has a successfully
established transport connection and is currently
delaying the sending of a BGP open message.
定義: 首尾よく設立された輸送接続があって、現在BGPの開いているメッセージの発信を遅らせている同輩のために有効なオープンメッセージを受け取ったとき、イベントは発生しています。
Status: Optional
状態: 任意
Optional
Attribute
Status: 1) The DelayOpen attribute SHOULD be set to TRUE.
2) The DelayOpenTimer SHOULD be running.
任意の属性状態: 1) DelayOpenはSHOULDを結果と考えます。TRUEに、用意ができています。 2) DelayOpenTimer SHOULD、稼働になってください。
Event 21: BGPHeaderErr
イベント21: BGPHeaderErr
Definition: An event is generated when a received BGP message
header is not valid.
定義: 容認されたBGPメッセージヘッダーが有効でないときに、イベントは発生しています。
Status: Mandatory
状態: 義務的
Event 22: BGPOpenMsgErr
イベント22: BGPOpenMsgErr
Definition: An event is generated when an OPEN message has been
received with errors.
定義: 誤りでオープンメッセージを受け取ったとき、イベントは発生しています。
Status: Mandatory
状態: 義務的
Event 23: OpenCollisionDump
イベント23: OpenCollisionDump
Definition: An event generated administratively when a
connection collision has been detected while
processing an incoming OPEN message and this
定義: 接続衝突が入って来るオープンメッセージとこれを処理している間検出されているとき行政上生成されたイベント
Rekhter, et al. Standards Track [Page 49] RFC 4271 BGP-4 January 2006
Rekhter、他 標準化過程[49ページ]RFC4271BGP-2006年1月4日
connection has been selected to be disconnected.
See Section 6.8 for more information on collision
detection.
接続は切断されるのに選ばれました。 衝突検出の詳しい情報に関してセクション6.8を見てください。
Event 23 is an administrative action generated by
implementation logic that determines whether this
connection needs to be dropped per the rules in
Section 6.8. This event may occur if the FSM is
implemented as two linked state machines.
イベント23はこの接続が、セクション6.8で規則単位で下げられる必要であるかどうか決定する実装論理によって生成された管理動作です。 FSMが2台の繋がっている州のマシンとして実装されるなら、このイベントは起こるかもしれません。
Status: Optional
状態: 任意
Optional
Attribute
Status: If the state machine is to process this event in
the Established state,
1) CollisionDetectEstablishedState optional
attribute SHOULD be set to TRUE.
任意の属性状態: 州のマシンがEstablished状態、1における)このイベントを処理するつもりであるなら SHOULDを結果と考えてください。CollisionDetectEstablishedState任意である、TRUEに、用意ができています。
Please note: The OpenCollisionDump event can occur
in Idle, Connect, Active, OpenSent, and OpenConfirm
without any optional attributes being set.
注意してください: OpenCollisionDumpイベントはIdle、Connect、Active、OpenSent、およびOpenConfirmに設定される少しも任意の属性なしで起こることができます。
Event 24: NotifMsgVerErr
イベント24: NotifMsgVerErr
Definition: An event is generated when a NOTIFICATION message
with "version error" is received.
定義: 「バージョン誤り」があるNOTIFICATIONメッセージが受信されているとき、イベントは発生しています。
Status: Mandatory
状態: 義務的
Event 25: NotifMsg
イベント25: NotifMsg
Definition: An event is generated when a NOTIFICATION message
is received and the error code is anything but
"version error".
定義: エラーコードは、NOTIFICATIONメッセージが受信されているとき、イベントが発生していて、何にもかかわらず、「バージョン誤り」ですでも。
Status: Mandatory
状態: 義務的
Event 26: KeepAliveMsg
イベント26: KeepAliveMsg
Definition: An event is generated when a KEEPALIVE message is
received.
定義: KEEPALIVEメッセージが受信されているとき、イベントは発生しています。
Status: Mandatory
状態: 義務的
Rekhter, et al. Standards Track [Page 50] RFC 4271 BGP-4 January 2006
Rekhter、他 標準化過程[50ページ]RFC4271BGP-2006年1月4日
Event 27: UpdateMsg
イベント27: UpdateMsg
Definition: An event is generated when a valid UPDATE message
is received.
定義: 有効なUPDATEメッセージが受信されているとき、イベントは発生しています。
Status: Mandatory
状態: 義務的
Event 28: UpdateMsgErr
イベント28: UpdateMsgErr
Definition: An event is generated when an invalid UPDATE
message is received.
定義: 無効のUPDATEメッセージが受信されているとき、イベントは発生しています。
Status: Mandatory
状態: 義務的
8.2. Description of FSM
8.2. FSMの記述
8.2.1. FSM Definition
8.2.1. FSM定義
BGP MUST maintain a separate FSM for each configured peer. Each BGP peer paired in a potential connection will attempt to connect to the other, unless configured to remain in the idle state, or configured to remain passive. For the purpose of this discussion, the active or connecting side of the TCP connection (the side of a TCP connection sending the first TCP SYN packet) is called outgoing. The passive or listening side (the sender of the first SYN/ACK) is called an incoming connection. (See Section 8.2.1.1 for information on the terms active and passive used below.)
BGP MUSTはそれぞれの構成された同輩のために別々のFSMを維持します。 潜在的接続で対にされたそれぞれのBGP同輩は、もう片方に接続するのを試みるでしょう、活動していない州に残るために構成されるか、または受け身のままであるために構成されない場合。 この議論の目的のために、TCP接続(最初のTCP SYNパケットを送るTCP接続の側面)のアクティブであるか接続している側面は外向的であると呼ばれます。 受動態か聴取側(最初のSYN/ACKの送付者)が接続要求と呼ばれます。 (諸条件でアクティブな情報と受動態のための.1が以下で使用したセクション8.2.1を見てください。)
A BGP implementation MUST connect to and listen on TCP port 179 for incoming connections in addition to trying to connect to peers. For each incoming connection, a state machine MUST be instantiated. There exists a period in which the identity of the peer on the other end of an incoming connection is known, but the BGP identifier is not known. During this time, both an incoming and outgoing connection may exist for the same configured peering. This is referred to as a connection collision (see Section 6.8).
同輩に接しようとすることに加えて、BGP実装は、接続要求のためにポート179を接続して、TCPで聴かなければなりません。 各接続要求において、州のマシンを例示しなければなりません。 接続要求のもう一方の端の同輩のアイデンティティが知られている期間は存在していますが、BGP識別子は知られていません。 この間に、送受信の接続が同じように存在するかもしれない両方がじっと見ることを構成しました。 これは接続衝突と呼ばれます(セクション6.8を見てください)。
A BGP implementation will have, at most, one FSM for each configured peering, plus one FSM for each incoming TCP connection for which the peer has not yet been identified. Each FSM corresponds to exactly one TCP connection.
BGP実装は、それぞれの構成されたじっと見るために大部分に1FSMを持っていて、同輩がまだ特定されていないそれぞれの入って来るTCP接続のために1FSMを持つでしょう。 各FSMはまさに1つのTCP接続に文通しています。
There may be more than one connection between a pair of peers if the connections are configured to use a different pair of IP addresses. This is referred to as multiple "configured peerings" to the same peer.
接続がIPアドレスの異なった組を使用するために構成されるなら、1組の同輩の間には、1つ以上の接続があるかもしれません。 これは同じ同輩への複数の「構成されたpeerings」と呼ばれます。
Rekhter, et al. Standards Track [Page 51] RFC 4271 BGP-4 January 2006
Rekhter、他 標準化過程[51ページ]RFC4271BGP-2006年1月4日
8.2.1.1. Terms "active" and "passive"
8.2.1.1. 用語「アクティブ」、そして、「受動態」
The terms active and passive have been in the Internet operator's vocabulary for almost a decade and have proven useful. The words active and passive have slightly different meanings when applied to a TCP connection or a peer. There is only one active side and one passive side to any one TCP connection, per the definition above and the state machine below. When a BGP speaker is configured as active, it may end up on either the active or passive side of the connection that eventually gets established. Once the TCP connection is completed, it doesn't matter which end was active and which was passive. The only difference is in which side of the TCP connection has port number 179.
用語能動態と受動態は、およそ10年間の間、インターネットオペレータのボキャブラリーにはあって、有用であることが分かりました。 単語能動態と受動態には、TCP接続か同輩に適用されると、わずかに異なった意味があります。 どんな上の定義あたりのTCP接続と州のマシンへの1つのアクティブ側と1つの受け身側しかも以下にありません。 BGPスピーカーがアクティブであるとして構成されるとき、それは結局設立される接続のアクティブであるか受け身の側面で終わるかもしれません。 TCP接続がいったん終了されていると、どの終わりがアクティブであったか、そして、どれが受け身であったかは重要ではありません。 唯一の違いがTCP接続のどの側面にポートNo.179があるかであります。
8.2.1.2. FSM and Collision Detection
8.2.1.2. FSMと衝突検出
There is one FSM per BGP connection. When the connection collision occurs prior to determining what peer a connection is associated with, there may be two connections for one peer. After the connection collision is resolved (see Section 6.8), the FSM for the connection that is closed SHOULD be disposed.
BGP接続あたり1FSMがあります。 接続衝突が接続がどんな同輩に関連しているかを決定する前に起こるとき、1人の同輩のための2つの接続があるかもしれません。 接続衝突が決議された(セクション6.8を見ます)後に接続のためのFSMはSHOULDを閉じました。配列されます。
8.2.1.3. FSM and Optional Session Attributes
8.2.1.3. FSMと任意のセッション属性
Optional Session Attributes specify either attributes that act as flags (TRUE or FALSE) or optional timers. For optional attributes that act as flags, if the optional session attribute can be set to TRUE on the system, the corresponding BGP FSM actions must be supported. For example, if the following options can be set in a BGP implementation: AutoStart and PassiveTcpEstablishment, then Events 3, 4 and 5 must be supported. If an Optional Session attribute cannot be set to TRUE, the events supporting that set of options do not have to be supported.
任意のSession Attributesは旗(TRUEかFALSE)として機能する属性か任意のタイマのどちらかを指定します。 システムの上に任意のセッション属性をTRUEに設定できるなら旗として機能する任意の属性において、対応するBGP FSM動作をサポートしなければなりません。 例えば、以下のオプションがそうであることができるなら、BGP実装でセットしてください: AutoStartとPassiveTcpEstablishment、そして、Events3、4、および5をサポートしなければなりません。 Optional Session属性をTRUEに設定できないなら、そのセットのオプションをサポートするイベントはサポートされる必要はありません。
Each of the optional timers (DelayOpenTimer and IdleHoldTimer) has a group of attributes that are:
それぞれの任意のタイマ(DelayOpenTimerとIdleHoldTimer)には、以下の通りである属性のグループがあります。
- flag indicating support,
- Time set in Timer
- Timer.
- サポートを示しながら、弛んでください--時間はTimerにセットしました--タイマ。
The two optional timers show this format:
2個の任意のタイマがこの書式を示しています:
DelayOpenTimer: DelayOpen, DelayOpenTime, DelayOpenTimer
IdleHoldTimer: DampPeerOscillations, IdleHoldTime,
IdleHoldTimer
DelayOpenTimer: DelayOpen、DelayOpenTime、DelayOpenTimer IdleHoldTimer: DampPeerOscillations、IdleHoldTime、IdleHoldTimer
Rekhter, et al. Standards Track [Page 52] RFC 4271 BGP-4 January 2006
Rekhter、他 標準化過程[52ページ]RFC4271BGP-2006年1月4日
If the flag indicating support for an optional timer (DelayOpen or DampPeerOscillations) cannot be set to TRUE, the timers and events supporting that option do not have to be supported.
任意のタイマ(DelayOpenかDampPeerOscillations)のサポートを示す旗をTRUEに設定できないなら、そのオプションをサポートするタイマとイベントは支えられる必要はありません。
8.2.1.4. FSM Event Numbers
8.2.1.4. FSMイベント番号
The Event numbers (1-28) utilized in this state machine description aid in specifying the behavior of the BGP state machine. Implementations MAY use these numbers to provide network management information. The exact form of an FSM or the FSM events are specific to each implementation.
この状態で利用されたEvent番号(1-28)はBGP州のマシンの働きを指定する際に記述援助を機械加工します。 実装は、ネットワークマネージメント情報を提供するのにこれらの数を使用するかもしれません。 FSMの正確なフォームかFSMイベントが各実装に特定です。
8.2.1.5. FSM Actions that are Implementation Dependent
8.2.1.5. Implementation DependentであるFSM Actions
At certain points, the BGP FSM specifies that BGP initialization will occur or that BGP resources will be deleted. The initialization of the BGP FSM and the associated resources depend on the policy portion of the BGP implementation. The details of these actions are outside the scope of the FSM document.
ある一定のポイントでは、BGP FSMは、BGP初期化が起こるか、またはBGPリソースが削除されると指定します。 BGP FSMの初期化と関連リソースはBGP実装の方針部分によります。 FSMドキュメントの範囲の外にこれらの動作の詳細があります。
8.2.2. Finite State Machine
8.2.2. 有限状態機械
Idle state:
状態を空費してください:
Initially, the BGP peer FSM is in the Idle state. Hereafter, the
BGP peer FSM will be shortened to BGP FSM.
初めは、BGP同輩FSMがIdle状態にあります。 今後、BGP同輩FSMはBGP FSMに短くされるでしょう。
In this state, BGP FSM refuses all incoming BGP connections for
this peer. No resources are allocated to the peer. In response
to a ManualStart event (Event 1) or an AutomaticStart event (Event
3), the local system:
この状態では、BGP FSMはこの同輩のためにすべての入って来るBGP接続を拒否します。 リソースを全く同輩に割り当てません。 ManualStartイベント(イベント1)かAutomaticStartイベント(イベント3)、ローカルシステムに対応して:
- initializes all BGP resources for the peer connection,
- 同輩接続のためにすべてのBGPリソースを初期化します。
- sets ConnectRetryCounter to zero,
- ゼロにConnectRetryCounterを設定します。
- starts the ConnectRetryTimer with the initial value,
- 初期の値からConnectRetryTimerを始動します。
- initiates a TCP connection to the other BGP peer,
- もう片方のBGP同輩にTCP接続を開始します。
- listens for a connection that may be initiated by the remote
BGP peer, and
- そしてリモートBGP同輩によって開始されるかもしれない接続の聞こうとする。
- changes its state to Connect.
- 状態をConnectに変えます。
The ManualStop event (Event 2) and AutomaticStop (Event 8) event
are ignored in the Idle state.
ManualStopイベント(イベント2)とAutomaticStop(イベント8)イベントはIdle状態で無視されます。
Rekhter, et al. Standards Track [Page 53] RFC 4271 BGP-4 January 2006
Rekhter、他 標準化過程[53ページ]RFC4271BGP-2006年1月4日
In response to a ManualStart_with_PassiveTcpEstablishment event
(Event 4) or AutomaticStart_with_PassiveTcpEstablishment event
(Event 5), the local system:
_PassiveTcpEstablishmentイベント(イベント4)があるManualStart_か_PassiveTcpEstablishmentイベント(イベント5)、ローカルシステムがあるAutomaticStart_に対応して:
- initializes all BGP resources,
- すべてのBGPリソースを初期化します。
- sets the ConnectRetryCounter to zero,
- ゼロにConnectRetryCounterを設定します。
- starts the ConnectRetryTimer with the initial value,
- 初期の値からConnectRetryTimerを始動します。
- listens for a connection that may be initiated by the remote
peer, and
- そしてリモート同輩によって開始されるかもしれない接続の聞こうとする。
- changes its state to Active.
- 状態をActiveに変えます。
The exact value of the ConnectRetryTimer is a local matter, but it
SHOULD be sufficiently large to allow TCP initialization.
ConnectRetryTimerの正確な値は地域にかかわる事柄ですが、それはSHOULDです。TCP初期化を許すことができるくらい大きくいてください。
If the DampPeerOscillations attribute is set to TRUE, the
following three additional events may occur within the Idle state:
DampPeerOscillations属性がTRUEに設定されるなら、以下の3つの追加イベントがIdle州の中に起こるかもしれません:
- AutomaticStart_with_DampPeerOscillations (Event 6),
- _DampPeerOscillations(イベント6)とAutomaticStart_
- AutomaticStart_with_DampPeerOscillations_and_
PassiveTcpEstablishment (Event 7),
- _DampPeerOscillations_と_PassiveTcpEstablishment(イベント7)とAutomaticStart_
- IdleHoldTimer_Expires (Event 13).
- IdleHoldTimer_は(イベント13)を吐き出します。
Upon receiving these 3 events, the local system will use these
events to prevent peer oscillations. The method of preventing
persistent peer oscillation is outside the scope of this document.
これらの3つのイベントを受けると、ローカルシステムは、同輩振動を防ぐのにこれらのイベントを使用するでしょう。 このドキュメントの範囲の外に永続的な同輩振動を防ぐメソッドがあります。
Any other event (Events 9-12, 15-28) received in the Idle state
does not cause change in the state of the local system.
Idle状態に受け取られたいかなる他のイベント(15-28のイベント9-12)もローカルシステムの事情の変化を引き起こしません。
Connect State:
状態をつなげてください:
In this state, BGP FSM is waiting for the TCP connection to be
completed.
この状態では、BGP FSMは、TCP接続が終了するのを待っています。
The start events (Events 1, 3-7) are ignored in the Connect state.
スタートイベント(3-7のイベント1)はConnect状態で無視されます。
In response to a ManualStop event (Event 2), the local system:
ManualStopイベント(イベント2)、ローカルシステムに対応して:
- drops the TCP connection,
- TCP接続を下げます。
- releases all BGP resources,
- すべてのBGPリソースを発表します。
Rekhter, et al. Standards Track [Page 54] RFC 4271 BGP-4 January 2006
Rekhter、他 標準化過程[54ページ]RFC4271BGP-2006年1月4日
- sets ConnectRetryCounter to zero,
- ゼロにConnectRetryCounterを設定します。
- stops the ConnectRetryTimer and sets ConnectRetryTimer to
zero, and
- そしてConnectRetryTimerを止めて、ゼロにConnectRetryTimerを設定する。
- changes its state to Idle.
- 状態をIdleに変えます。
In response to the ConnectRetryTimer_Expires event (Event 9), the
local system:
ConnectRetryTimer_Expiresイベント(イベント9)、ローカルシステムに対応して:
- drops the TCP connection,
- TCP接続を下げます。
- restarts the ConnectRetryTimer,
- ConnectRetryTimerを再開します。
- stops the DelayOpenTimer and resets the timer to zero,
- DelayOpenTimerを止めて、ゼロにタイマをリセットします。
- initiates a TCP connection to the other BGP peer,
- もう片方のBGP同輩にTCP接続を開始します。
- continues to listen for a connection that may be initiated by
the remote BGP peer, and
- そしてリモートBGP同輩によって開始されるかもしれない接続の聞こうとし続けている。
- stays in the Connect state.
- Connect状態での滞在。
If the DelayOpenTimer_Expires event (Event 12) occurs in the
Connect state, the local system:
DelayOpenTimer_Expiresイベント(イベント12)がConnect状態、ローカルシステムで起こるなら:
- sends an OPEN message to its peer,
- オープンメッセージを同輩に送ります。
- sets the HoldTimer to a large value, and
- そして大きい値にHoldTimerを設定する。
- changes its state to OpenSent.
- 状態をOpenSentに変えます。
If the BGP FSM receives a TcpConnection_Valid event (Event 14),
the TCP connection is processed, and the connection remains in the
Connect state.
BGP FSMがTcpConnection_Validイベント(イベント14)を受けるなら、TCP接続は処理されます、そして、接続はConnect州に留まっています。
If the BGP FSM receives a Tcp_CR_Invalid event (Event 15), the
local system rejects the TCP connection, and the connection
remains in the Connect state.
BGP FSMがTcp_CR_Invalidイベント(イベント15)を受けるなら、ローカルシステムはTCP接続を拒絶します、そして、接続はConnect州に留まっています。
If the TCP connection succeeds (Event 16 or Event 17), the local
system checks the DelayOpen attribute prior to processing. If the
DelayOpen attribute is set to TRUE, the local system:
TCP接続が(イベント16かEvent17)を引き継ぐなら、ローカルシステムは処理の前にDelayOpen属性をチェックします。 DelayOpen属性がTRUE、ローカルシステムに設定されるなら:
- stops the ConnectRetryTimer (if running) and sets the
ConnectRetryTimer to zero,
- ConnectRetryTimer(稼働しているなら)を止めて、ゼロにConnectRetryTimerを設定します。
- sets the DelayOpenTimer to the initial value, and
- そして初期の値にDelayOpenTimerを設定する。
Rekhter, et al. Standards Track [Page 55] RFC 4271 BGP-4 January 2006
Rekhter、他 標準化過程[55ページ]RFC4271BGP-2006年1月4日
- stays in the Connect state.
- Connect状態での滞在。
If the DelayOpen attribute is set to FALSE, the local system:
DelayOpen属性がFALSE、ローカルシステムに設定されるなら:
- stops the ConnectRetryTimer (if running) and sets the
ConnectRetryTimer to zero,
- ConnectRetryTimer(稼働しているなら)を止めて、ゼロにConnectRetryTimerを設定します。
- completes BGP initialization
- BGP初期化を終了します。
- sends an OPEN message to its peer,
- オープンメッセージを同輩に送ります。
- sets the HoldTimer to a large value, and
- そして大きい値にHoldTimerを設定する。
- changes its state to OpenSent.
- 状態をOpenSentに変えます。
A HoldTimer value of 4 minutes is suggested.
4分のHoldTimer値は示されます。
If the TCP connection fails (Event 18), the local system checks
the DelayOpenTimer. If the DelayOpenTimer is running, the local
system:
TCP接続が(イベント18)に失敗するなら、ローカルシステムはDelayOpenTimerをチェックします。 DelayOpenTimerが稼働、ローカルシステムであるなら:
- restarts the ConnectRetryTimer with the initial value,
- 初期の値でConnectRetryTimerを再開します。
- stops the DelayOpenTimer and resets its value to zero,
- DelayOpenTimerを止めて、ゼロに値をリセットします。
- continues to listen for a connection that may be initiated by
the remote BGP peer, and
- そしてリモートBGP同輩によって開始されるかもしれない接続の聞こうとし続けている。
- changes its state to Active.
- 状態をActiveに変えます。
If the DelayOpenTimer is not running, the local system:
DelayOpenTimerが稼働、ローカルシステムでないなら:
- stops the ConnectRetryTimer to zero,
- ConnectRetryTimerをゼロまで止めます。
- drops the TCP connection,
- TCP接続を下げます。
- releases all BGP resources, and
- そしてすべてのBGPリソースを発表する。
- changes its state to Idle.
- 状態をIdleに変えます。
If an OPEN message is received while the DelayOpenTimer is running
(Event 20), the local system:
DelayOpenTimerが稼働(イベント20)、ローカルシステムですが、オープンメッセージが受信されているなら:
- stops the ConnectRetryTimer (if running) and sets the
ConnectRetryTimer to zero,
- ConnectRetryTimer(稼働しているなら)を止めて、ゼロにConnectRetryTimerを設定します。
- completes the BGP initialization,
- BGP初期化を終了します。
Rekhter, et al. Standards Track [Page 56] RFC 4271 BGP-4 January 2006
Rekhter、他 標準化過程[56ページ]RFC4271BGP-2006年1月4日
- stops and clears the DelayOpenTimer (sets the value to zero),
- DelayOpenTimer(ゼロに値を設定する)を止めて、きれいにします。
- sends an OPEN message,
- オープンメッセージを送ります。
- sends a KEEPALIVE message,
- KEEPALIVEメッセージを送ります。
- if the HoldTimer initial value is non-zero,
- HoldTimerの初期の値が非ゼロであるなら
- starts the KeepaliveTimer with the initial value and
- そして初期の値からKeepaliveTimerを始動する。
- resets the HoldTimer to the negotiated value,
- 交渉された値にHoldTimerをリセットします。
else, if the HoldTimer initial value is zero,
ほかに、HoldTimerであるなら、初期の値はゼロです。
- resets the KeepaliveTimer and
- そしてKeepaliveTimerをリセットする。
- resets the HoldTimer value to zero,
- HoldTimerがゼロに評価するリセット
- and changes its state to OpenConfirm.
- そして、状態をOpenConfirmに変えます。
If the value of the autonomous system field is the same as the
local Autonomous System number, set the connection status to an
internal connection; otherwise it will be "external".
自律システム分野の値が地方のAutonomous System番号と同じであるなら、内部の接続に接続形態を設定してください。 さもなければ、それは「外部でしょう」。
If BGP message header checking (Event 21) or OPEN message checking
detects an error (Event 22) (see Section 6.2), the local system:
BGPであるなら、(イベント21)かオープンメッセージの照合をチェックするメッセージヘッダーが誤り(イベント22)を検出します(セクション6.2を見てください)、ローカルシステム:
- (optionally) If the SendNOTIFICATIONwithoutOPEN attribute is
set to TRUE, then the local system first sends a NOTIFICATION
message with the appropriate error code, and then
- (任意に) SendNOTIFICATIONwithoutOPEN属性がTRUEに設定されるなら、ローカルシステムは最初に、適切なエラーコード、およびその時があるNOTIFICATIONメッセージを送ります。
- stops the ConnectRetryTimer (if running) and sets the
ConnectRetryTimer to zero,
- ConnectRetryTimer(稼働しているなら)を止めて、ゼロにConnectRetryTimerを設定します。
- releases all BGP resources,
- すべてのBGPリソースを発表します。
- drops the TCP connection,
- TCP接続を下げます。
- increments the ConnectRetryCounter by 1,
- ConnectRetryCounterを1つ増加します。
- (optionally) performs peer oscillation damping if the
DampPeerOscillations attribute is set to TRUE, and
- そしてDampPeerOscillations属性がTRUEに設定されるなら(任意に)同輩振動湿気を実行する。
- changes its state to Idle.
- 状態をIdleに変えます。
If a NOTIFICATION message is received with a version error (Event
24), the local system checks the DelayOpenTimer. If the
DelayOpenTimer is running, the local system:
バージョン誤り(イベント24)でNOTIFICATIONメッセージを受け取るなら、ローカルシステムはDelayOpenTimerをチェックします。 DelayOpenTimerが稼働、ローカルシステムであるなら:
Rekhter, et al. Standards Track [Page 57] RFC 4271 BGP-4 January 2006
Rekhter、他 標準化過程[57ページ]RFC4271BGP-2006年1月4日
- stops the ConnectRetryTimer (if running) and sets the
ConnectRetryTimer to zero,
- ConnectRetryTimer(稼働しているなら)を止めて、ゼロにConnectRetryTimerを設定します。
- stops and resets the DelayOpenTimer (sets to zero),
- DelayOpenTimer(ゼロに設定する)を止めて、リセットします。
- releases all BGP resources,
- すべてのBGPリソースを発表します。
- drops the TCP connection, and
- そしてTCP接続を下げる。
- changes its state to Idle.
- 状態をIdleに変えます。
If the DelayOpenTimer is not running, the local system:
DelayOpenTimerが稼働、ローカルシステムでないなら:
- stops the ConnectRetryTimer and sets the ConnectRetryTimer to
zero,
- ConnectRetryTimerを止めて、ゼロにConnectRetryTimerを設定します。
- releases all BGP resources,
- すべてのBGPリソースを発表します。
- drops the TCP connection,
- TCP接続を下げます。
- increments the ConnectRetryCounter by 1,
- ConnectRetryCounterを1つ増加します。
- performs peer oscillation damping if the DampPeerOscillations
attribute is set to True, and
- そしてDampPeerOscillations属性がTrueに設定されるなら同輩振動湿気を実行する。
- changes its state to Idle.
- 状態をIdleに変えます。
In response to any other events (Events 8, 10-11, 13, 19, 23,
25-28), the local system:
いかなる他のイベント(イベント8、25-28の10-11 13、19、23)、ローカルシステムに対応して:
- if the ConnectRetryTimer is running, stops and resets the
ConnectRetryTimer (sets to zero),
- ConnectRetryTimerがConnectRetryTimerを実行であり、止めて、リセットするなら(ゼロに設定します)
- if the DelayOpenTimer is running, stops and resets the
DelayOpenTimer (sets to zero),
- DelayOpenTimerがDelayOpenTimerを実行であり、止めて、リセットするなら(ゼロに設定します)
- releases all BGP resources,
- すべてのBGPリソースを発表します。
- drops the TCP connection,
- TCP接続を下げます。
- increments the ConnectRetryCounter by 1,
- ConnectRetryCounterを1つ増加します。
- performs peer oscillation damping if the DampPeerOscillations
attribute is set to True, and
- そしてDampPeerOscillations属性がTrueに設定されるなら同輩振動湿気を実行する。
- changes its state to Idle.
- 状態をIdleに変えます。
Rekhter, et al. Standards Track [Page 58] RFC 4271 BGP-4 January 2006
Rekhter、他 標準化過程[58ページ]RFC4271BGP-2006年1月4日
Active State:
活動的な州:
In this state, BGP FSM is trying to acquire a peer by listening
for, and accepting, a TCP connection.
この状態では、BGP FSMは、TCP接続を聞こうとして、受け入れることによって、同輩を取得しようとしています。
The start events (Events 1, 3-7) are ignored in the Active state.
スタートイベント(3-7のイベント1)はActive状態で無視されます。
In response to a ManualStop event (Event 2), the local system:
ManualStopイベント(イベント2)、ローカルシステムに対応して:
- If the DelayOpenTimer is running and the
SendNOTIFICATIONwithoutOPEN session attribute is set, the
local system sends a NOTIFICATION with a Cease,
- DelayOpenTimerが稼働する予定であり、SendNOTIFICATIONwithoutOPENセッション属性が設定されるなら、ローカルシステムはCeaseと共に通知書を送っています。
- releases all BGP resources including stopping the
DelayOpenTimer
- DelayOpenTimerを止めるのを含むすべてのBGPリソースを発表します。
- drops the TCP connection,
- TCP接続を下げます。
- sets ConnectRetryCounter to zero,
- ゼロにConnectRetryCounterを設定します。
- stops the ConnectRetryTimer and sets the ConnectRetryTimer to
zero, and
- そしてConnectRetryTimerを止めて、ゼロにConnectRetryTimerを設定する。
- changes its state to Idle.
- 状態をIdleに変えます。
In response to a ConnectRetryTimer_Expires event (Event 9), the
local system:
ConnectRetryTimer_Expiresイベント(イベント9)、ローカルシステムに対応して:
- restarts the ConnectRetryTimer (with initial value),
- ConnectRetryTimer(初期の値がある)を再開します。
- initiates a TCP connection to the other BGP peer,
- もう片方のBGP同輩にTCP接続を開始します。
- continues to listen for a TCP connection that may be initiated
by a remote BGP peer, and
- そしてリモートBGP同輩によって開始されるかもしれないTCP接続の聞こうとし続けている。
- changes its state to Connect.
- 状態をConnectに変えます。
If the local system receives a DelayOpenTimer_Expires event (Event
12), the local system:
ローカルシステムがDelayOpenTimer_Expiresイベント(イベント12)、ローカルシステムを受け取るなら:
- sets the ConnectRetryTimer to zero,
- ゼロにConnectRetryTimerを設定します。
- stops and clears the DelayOpenTimer (set to zero),
- DelayOpenTimer(ゼロに設定する)を止めて、きれいにします。
- completes the BGP initialization,
- BGP初期化を終了します。
- sends the OPEN message to its remote peer,
- オープンメッセージをリモート同輩に送ります。
Rekhter, et al. Standards Track [Page 59] RFC 4271 BGP-4 January 2006
Rekhter、他 標準化過程[59ページ]RFC4271BGP-2006年1月4日
- sets its hold timer to a large value, and
- そして大きい値に保持タイマを設定する。
- changes its state to OpenSent.
- 状態をOpenSentに変えます。
A HoldTimer value of 4 minutes is also suggested for this state
transition.
また、4分のHoldTimer値はこの状態遷移のために示されます。
If the local system receives a TcpConnection_Valid event (Event
14), the local system processes the TCP connection flags and stays
in the Active state.
ローカルシステムがTcpConnection_Validイベント(イベント14)を受けるなら、ローカルシステムは、TCP接続旗を処理して、Active状態にいます。
If the local system receives a Tcp_CR_Invalid event (Event 15),
the local system rejects the TCP connection and stays in the
Active State.
ローカルシステムがTcp_CR_Invalidイベント(イベント15)を受けるなら、ローカルシステムは、TCP接続を拒絶して、Active州に残っています。
In response to the success of a TCP connection (Event 16 or Event
17), the local system checks the DelayOpen optional attribute
prior to processing.
TCP接続(イベント16かEvent17)の成功に対応して、ローカルシステムは処理の前にDelayOpenの任意の属性をチェックします。
If the DelayOpen attribute is set to TRUE, the local system:
DelayOpen属性がTRUE、ローカルシステムに設定されるなら:
- stops the ConnectRetryTimer and sets the ConnectRetryTimer
to zero,
- ConnectRetryTimerを止めて、ゼロにConnectRetryTimerを設定します。
- sets the DelayOpenTimer to the initial value
(DelayOpenTime), and
- そして初期の値(DelayOpenTime)にDelayOpenTimerを設定する。
- stays in the Active state.
- Active状態での滞在。
If the DelayOpen attribute is set to FALSE, the local system:
DelayOpen属性がFALSE、ローカルシステムに設定されるなら:
- sets the ConnectRetryTimer to zero,
- ゼロにConnectRetryTimerを設定します。
- completes the BGP initialization,
- BGP初期化を終了します。
- sends the OPEN message to its peer,
- オープンメッセージを同輩に送ります。
- sets its HoldTimer to a large value, and
- そして大きい値にHoldTimerを設定する。
- changes its state to OpenSent.
- 状態をOpenSentに変えます。
A HoldTimer value of 4 minutes is suggested as a "large value" for
the HoldTimer.
4分のHoldTimer値はHoldTimerのための「大きい値」として示されます。
If the local system receives a TcpConnectionFails event (Event
18), the local system:
ローカルシステムがTcpConnectionFailsイベント(イベント18)、ローカルシステムを受け取るなら:
- restarts the ConnectRetryTimer (with the initial value),
- ConnectRetryTimer(初期の値がある)を再開します。
Rekhter, et al. Standards Track [Page 60] RFC 4271 BGP-4 January 2006
Rekhter、他 標準化過程[60ページ]RFC4271BGP-2006年1月4日
- stops and clears the DelayOpenTimer (sets the value to zero),
- DelayOpenTimer(ゼロに値を設定する)を止めて、きれいにします。
- releases all BGP resource,
- すべてのBGPリソースを発表します。
- increments the ConnectRetryCounter by 1,
- ConnectRetryCounterを1つ増加します。
- optionally performs peer oscillation damping if the
DampPeerOscillations attribute is set to TRUE, and
- そしてDampPeerOscillations属性がTRUEに設定されるなら任意に同輩振動湿気を実行する。
- changes its state to Idle.
- 状態をIdleに変えます。
If an OPEN message is received and the DelayOpenTimer is running
(Event 20), the local system:
オープンメッセージが受信されているなら、DelayOpenTimerは稼働(イベント20)、ローカルシステムです:
- stops the ConnectRetryTimer (if running) and sets the
ConnectRetryTimer to zero,
- ConnectRetryTimer(稼働しているなら)を止めて、ゼロにConnectRetryTimerを設定します。
- stops and clears the DelayOpenTimer (sets to zero),
- DelayOpenTimer(ゼロに設定する)を止めて、きれいにします。
- completes the BGP initialization,
- BGP初期化を終了します。
- sends an OPEN message,
- オープンメッセージを送ります。
- sends a KEEPALIVE message,
- KEEPALIVEメッセージを送ります。
- if the HoldTimer value is non-zero,
- HoldTimer値が非ゼロであるなら
- starts the KeepaliveTimer to initial value,
- 値に頭文字をつけるためにKeepaliveTimerを始動します。
- resets the HoldTimer to the negotiated value,
- 交渉された値にHoldTimerをリセットします。
else if the HoldTimer is zero
ほか、HoldTimerはゼロです。
- resets the KeepaliveTimer (set to zero),
- KeepaliveTimer(ゼロに設定する)をリセットします。
- resets the HoldTimer to zero, and
- そしてゼロにHoldTimerをリセットする。
- changes its state to OpenConfirm.
- 状態をOpenConfirmに変えます。
If the value of the autonomous system field is the same as the
local Autonomous System number, set the connection status to an
internal connection; otherwise it will be external.
自律システム分野の値が地方のAutonomous System番号と同じであるなら、内部の接続に接続形態を設定してください。 さもなければ、それは外部になるでしょう。
If BGP message header checking (Event 21) or OPEN message checking
detects an error (Event 22) (see Section 6.2), the local system:
BGPであるなら、(イベント21)かオープンメッセージの照合をチェックするメッセージヘッダーが誤り(イベント22)を検出します(セクション6.2を見てください)、ローカルシステム:
Rekhter, et al. Standards Track [Page 61] RFC 4271 BGP-4 January 2006
Rekhter、他 標準化過程[61ページ]RFC4271BGP-2006年1月4日
- (optionally) sends a NOTIFICATION message with the appropriate
error code if the SendNOTIFICATIONwithoutOPEN attribute is set
to TRUE,
- (任意に、)SendNOTIFICATIONwithoutOPEN属性がTRUEに設定されるなら、適切なエラーコードがあるNOTIFICATIONメッセージを送ります。
- sets the ConnectRetryTimer to zero,
- ゼロにConnectRetryTimerを設定します。
- releases all BGP resources,
- すべてのBGPリソースを発表します。
- drops the TCP connection,
- TCP接続を下げます。
- increments the ConnectRetryCounter by 1,
- ConnectRetryCounterを1つ増加します。
- (optionally) performs peer oscillation damping if the
DampPeerOscillations attribute is set to TRUE, and
- そしてDampPeerOscillations属性がTRUEに設定されるなら(任意に)同輩振動湿気を実行する。
- changes its state to Idle.
- 状態をIdleに変えます。
If a NOTIFICATION message is received with a version error (Event
24), the local system checks the DelayOpenTimer. If the
DelayOpenTimer is running, the local system:
バージョン誤り(イベント24)でNOTIFICATIONメッセージを受け取るなら、ローカルシステムはDelayOpenTimerをチェックします。 DelayOpenTimerが稼働、ローカルシステムであるなら:
- stops the ConnectRetryTimer (if running) and sets the
ConnectRetryTimer to zero,
- ConnectRetryTimer(稼働しているなら)を止めて、ゼロにConnectRetryTimerを設定します。
- stops and resets the DelayOpenTimer (sets to zero),
- DelayOpenTimer(ゼロに設定する)を止めて、リセットします。
- releases all BGP resources,
- すべてのBGPリソースを発表します。
- drops the TCP connection, and
- そしてTCP接続を下げる。
- changes its state to Idle.
- 状態をIdleに変えます。
If the DelayOpenTimer is not running, the local system:
DelayOpenTimerが稼働、ローカルシステムでないなら:
- sets the ConnectRetryTimer to zero,
- ゼロにConnectRetryTimerを設定します。
- releases all BGP resources,
- すべてのBGPリソースを発表します。
- drops the TCP connection,
- TCP接続を下げます。
- increments the ConnectRetryCounter by 1,
- ConnectRetryCounterを1つ増加します。
- (optionally) performs peer oscillation damping if the
DampPeerOscillations attribute is set to TRUE, and
- そしてDampPeerOscillations属性がTRUEに設定されるなら(任意に)同輩振動湿気を実行する。
- changes its state to Idle.
- 状態をIdleに変えます。
Rekhter, et al. Standards Track [Page 62] RFC 4271 BGP-4 January 2006
Rekhter、他 標準化過程[62ページ]RFC4271BGP-2006年1月4日
In response to any other event (Events 8, 10-11, 13, 19, 23,
25-28), the local system:
いかなる他のイベント(イベント8、25-28の10-11 13、19、23)、ローカルシステムに対応して:
- sets the ConnectRetryTimer to zero,
- ゼロにConnectRetryTimerを設定します。
- releases all BGP resources,
- すべてのBGPリソースを発表します。
- drops the TCP connection,
- TCP接続を下げます。
- increments the ConnectRetryCounter by one,
- ConnectRetryCounterを1つ増加します。
- (optionally) performs peer oscillation damping if the
DampPeerOscillations attribute is set to TRUE, and
- そしてDampPeerOscillations属性がTRUEに設定されるなら(任意に)同輩振動湿気を実行する。
- changes its state to Idle.
- 状態をIdleに変えます。
OpenSent:
OpenSent:
In this state, BGP FSM waits for an OPEN message from its peer.
この状態では、BGP FSMは同輩からのオープンメッセージを待っています。
The start events (Events 1, 3-7) are ignored in the OpenSent
state.
スタートイベント(3-7のイベント1)はOpenSent状態で無視されます。
If a ManualStop event (Event 2) is issued in the OpenSent state,
the local system:
ManualStopイベント(イベント2)がOpenSent状態、ローカルシステムで発行されるなら:
- sends the NOTIFICATION with a Cease,
- CeaseとNOTIFICATIONを送ります。
- sets the ConnectRetryTimer to zero,
- ゼロにConnectRetryTimerを設定します。
- releases all BGP resources,
- すべてのBGPリソースを発表します。
- drops the TCP connection,
- TCP接続を下げます。
- sets the ConnectRetryCounter to zero, and
- そしてゼロにConnectRetryCounterを設定する。
- changes its state to Idle.
- 状態をIdleに変えます。
If an AutomaticStop event (Event 8) is issued in the OpenSent
state, the local system:
AutomaticStopイベント(イベント8)がOpenSent状態、ローカルシステムで発行されるなら:
- sends the NOTIFICATION with a Cease,
- CeaseとNOTIFICATIONを送ります。
- sets the ConnectRetryTimer to zero,
- ゼロにConnectRetryTimerを設定します。
- releases all the BGP resources,
- すべてのBGPリソースを発表します。
- drops the TCP connection,
- TCP接続を下げます。
Rekhter, et al. Standards Track [Page 63] RFC 4271 BGP-4 January 2006
Rekhter、他 標準化過程[63ページ]RFC4271BGP-2006年1月4日
- increments the ConnectRetryCounter by 1,
- ConnectRetryCounterを1つ増加します。
- (optionally) performs peer oscillation damping if the
DampPeerOscillations attribute is set to TRUE, and
- そしてDampPeerOscillations属性がTRUEに設定されるなら(任意に)同輩振動湿気を実行する。
- changes its state to Idle.
- 状態をIdleに変えます。
If the HoldTimer_Expires (Event 10), the local system:
HoldTimer_Expires(イベント10)、ローカルシステムであるなら:
- sends a NOTIFICATION message with the error code Hold Timer
Expired,
- エラーコードHold Timer ExpiredがあるNOTIFICATIONメッセージを送ります。
- sets the ConnectRetryTimer to zero,
- ゼロにConnectRetryTimerを設定します。
- releases all BGP resources,
- すべてのBGPリソースを発表します。
- drops the TCP connection,
- TCP接続を下げます。
- increments the ConnectRetryCounter,
- ConnectRetryCounterを増加します。
- (optionally) performs peer oscillation damping if the
DampPeerOscillations attribute is set to TRUE, and
- そしてDampPeerOscillations属性がTRUEに設定されるなら(任意に)同輩振動湿気を実行する。
- changes its state to Idle.
- 状態をIdleに変えます。
If a TcpConnection_Valid (Event 14), Tcp_CR_Acked (Event 16), or a
TcpConnectionConfirmed event (Event 17) is received, a second TCP
connection may be in progress. This second TCP connection is
tracked per Connection Collision processing (Section 6.8) until an
OPEN message is received.
TcpConnection_Valid(イベント14)、Tcp_CR_Acked(イベント16)、またはTcpConnectionConfirmedイベント(イベント17)が受け取られているなら、2番目のTCP接続は進行しているかもしれません。 オープンメッセージが受信されるまで、この2番目のTCP接続はConnection Collision処理(セクション6.8)単位で追跡されます。
A TCP Connection Request for an Invalid port (Tcp_CR_Invalid
(Event 15)) is ignored.
Invalidポート(Tcp_CR_Invalid(イベント15))へのTCP Connection Requestは無視されます。
If a TcpConnectionFails event (Event 18) is received, the local
system:
受け取られたTcpConnectionFailsイベント(イベント18)、ローカルシステムであるなら:
- closes the BGP connection,
- BGP接続を終えます。
- restarts the ConnectRetryTimer,
- ConnectRetryTimerを再開します。
- continues to listen for a connection that may be initiated by
the remote BGP peer, and
- そしてリモートBGP同輩によって開始されるかもしれない接続の聞こうとし続けている。
- changes its state to Active.
- 状態をActiveに変えます。
Rekhter, et al. Standards Track [Page 64] RFC 4271 BGP-4 January 2006
Rekhter、他 標準化過程[64ページ]RFC4271BGP-2006年1月4日
When an OPEN message is received, all fields are checked for
correctness. If there are no errors in the OPEN message (Event
19), the local system:
オープンメッセージが受信されているとき、すべての分野が正当性がないかどうかチェックされます。 オープンメッセージ(イベント19)、ローカルシステムに誤りが全くなければ:
- resets the DelayOpenTimer to zero,
- ゼロにDelayOpenTimerをリセットします。
- sets the BGP ConnectRetryTimer to zero,
- ゼロにBGP ConnectRetryTimerを設定します。
- sends a KEEPALIVE message, and
- そしてKEEPALIVEメッセージを送る。
- sets a KeepaliveTimer (via the text below)
- KeepaliveTimerを設定します。(以下のテキストを通した)
- sets the HoldTimer according to the negotiated value (see
Section 4.2),
- 交渉された値(セクション4.2を見る)に従って、HoldTimerを設定します。
- changes its state to OpenConfirm.
- 状態をOpenConfirmに変えます。
If the negotiated hold time value is zero, then the HoldTimer and
KeepaliveTimer 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
an "external" connection. (This will impact UPDATE processing as
described below.)
交渉された保持時間値がゼロであるなら、HoldTimerとKeepaliveTimerは始動されません。 Autonomous System分野の値が地方のAutonomous System番号と同じであるなら、接続は「内部」の接続です。 さもなければ、それは「外部」の接続です。 (これは以下で説明されるようにUPDATE処理に影響を与えるでしょう。)
If the BGP message header checking (Event 21) or OPEN message
checking detects an error (Event 22)(see Section 6.2), the local
system:
BGPメッセージであるなら、(イベント21)かオープンメッセージの照合をチェックするヘッダーが誤り(イベント22)を検出します(セクション6.2を見てください)、ローカルシステム:
- sends a NOTIFICATION message with the appropriate error code,
- 適切なエラーコードがあるNOTIFICATIONメッセージを送ります。
- sets the ConnectRetryTimer to zero,
- ゼロにConnectRetryTimerを設定します。
- releases all BGP resources,
- すべてのBGPリソースを発表します。
- drops the TCP connection,
- TCP接続を下げます。
- increments the ConnectRetryCounter by 1,
- ConnectRetryCounterを1つ増加します。
- (optionally) performs peer oscillation damping if the
DampPeerOscillations attribute is TRUE, and
- そしてDampPeerOscillations属性がTRUEであるなら(任意に)同輩振動湿気を実行する。
- changes its state to Idle.
- 状態をIdleに変えます。
Collision detection mechanisms (Section 6.8) need to be applied
when a valid BGP OPEN message is received (Event 19 or Event 20).
Please refer to Section 6.8 for the details of the comparison. A
衝突検出メカニズム(セクション6.8)は、有効なBGP OPENメッセージが受信されているとき(イベント19かEvent20)、適用される必要があります。 比較の詳細についてセクション6.8を参照してください。 A
Rekhter, et al. Standards Track [Page 65] RFC 4271 BGP-4 January 2006
Rekhter、他 標準化過程[65ページ]RFC4271BGP-2006年1月4日
CollisionDetectDump event occurs when the BGP implementation
determines, by means outside the scope of this document, that a
connection collision has occurred.
BGP実装が、接続衝突が起こったことをこのドキュメントの範囲の外の手段で決定すると、CollisionDetectDumpイベントは起こります。
If a connection in the OpenSent state is determined to be the
connection that must be closed, an OpenCollisionDump (Event 23) is
signaled to the state machine. If such an event is received in
the OpenSent state, the local system:
OpenSent状態での接続が閉店しなければならない接続であることを決定しているなら、OpenCollisionDump(イベント23)は州のマシンに合図されます。 OpenSent状態、ローカルシステムでそのようなイベントを受け取るなら:
- sends a NOTIFICATION with a Cease,
- Ceaseと共に通知書を送っています。
- sets the ConnectRetryTimer to zero,
- ゼロにConnectRetryTimerを設定します。
- releases all BGP resources,
- すべてのBGPリソースを発表します。
- drops the TCP connection,
- TCP接続を下げます。
- increments the ConnectRetryCounter by 1,
- ConnectRetryCounterを1つ増加します。
- (optionally) performs peer oscillation damping if the
DampPeerOscillations attribute is set to TRUE, and
- そしてDampPeerOscillations属性がTRUEに設定されるなら(任意に)同輩振動湿気を実行する。
- changes its state to Idle.
- 状態をIdleに変えます。
If a NOTIFICATION message is received with a version error (Event
24), the local system:
バージョン誤り(イベント24)、ローカルシステムでNOTIFICATIONメッセージを受け取るなら:
- sets the ConnectRetryTimer to zero,
- ゼロにConnectRetryTimerを設定します。
- releases all BGP resources,
- すべてのBGPリソースを発表します。
- drops the TCP connection, and
- そしてTCP接続を下げる。
- changes its state to Idle.
- 状態をIdleに変えます。
In response to any other event (Events 9, 11-13, 20, 25-28), the
local system:
いかなる他のイベント(イベント9、11-13、25-28の20)、ローカルシステムに対応して:
- sends the NOTIFICATION with the Error Code Finite State
Machine Error,
- Error Code Finite州Machine ErrorとNOTIFICATIONを送ります。
- sets the ConnectRetryTimer to zero,
- ゼロにConnectRetryTimerを設定します。
- releases all BGP resources,
- すべてのBGPリソースを発表します。
- drops the TCP connection,
- TCP接続を下げます。
- increments the ConnectRetryCounter by 1,
- ConnectRetryCounterを1つ増加します。
Rekhter, et al. Standards Track [Page 66] RFC 4271 BGP-4 January 2006
Rekhter、他 標準化過程[66ページ]RFC4271BGP-2006年1月4日
- (optionally) performs peer oscillation damping if the
DampPeerOscillations attribute is set to TRUE, and
- そしてDampPeerOscillations属性がTRUEに設定されるなら(任意に)同輩振動湿気を実行する。
- changes its state to Idle.
- 状態をIdleに変えます。
OpenConfirm State:
OpenConfirm州:
In this state, BGP waits for a KEEPALIVE or NOTIFICATION message.
この状態では、BGPはKEEPALIVEかNOTIFICATIONメッセージを待っています。
Any start event (Events 1, 3-7) is ignored in the OpenConfirm
state.
どんなスタートイベント(3-7のイベント1)もOpenConfirm状態で無視されます。
In response to a ManualStop event (Event 2) initiated by the
operator, the local system:
オペレータ、ローカルシステムによって開始されたManualStopイベント(イベント2)に対応して:
- sends the NOTIFICATION message with a Cease,
- CeaseがあるNOTIFICATIONメッセージを送ります。
- releases all BGP resources,
- すべてのBGPリソースを発表します。
- drops the TCP connection,
- TCP接続を下げます。
- sets the ConnectRetryCounter to zero,
- ゼロにConnectRetryCounterを設定します。
- sets the ConnectRetryTimer to zero, and
- そしてゼロにConnectRetryTimerを設定する。
- changes its state to Idle.
- 状態をIdleに変えます。
In response to the AutomaticStop event initiated by the system
(Event 8), the local system:
システム(イベント8)、ローカルシステムによって開始されたAutomaticStopイベントに対応して:
- sends the NOTIFICATION message with a Cease,
- CeaseがあるNOTIFICATIONメッセージを送ります。
- sets the ConnectRetryTimer to zero,
- ゼロにConnectRetryTimerを設定します。
- releases all BGP resources,
- すべてのBGPリソースを発表します。
- drops the TCP connection,
- TCP接続を下げます。
- increments the ConnectRetryCounter by 1,
- ConnectRetryCounterを1つ増加します。
- (optionally) performs peer oscillation damping if the
DampPeerOscillations attribute is set to TRUE, and
- そしてDampPeerOscillations属性がTRUEに設定されるなら(任意に)同輩振動湿気を実行する。
- changes its state to Idle.
- 状態をIdleに変えます。
If the HoldTimer_Expires event (Event 10) occurs before a
KEEPALIVE message is received, the local system:
HoldTimer_Expiresイベント(イベント10)が受け取られたKEEPALIVEメッセージ、ローカルシステムの前に起こるなら:
Rekhter, et al. Standards Track [Page 67] RFC 4271 BGP-4 January 2006
Rekhter、他 標準化過程[67ページ]RFC4271BGP-2006年1月4日
- sends the NOTIFICATION message with the Error Code Hold Timer
Expired,
- Error Code Hold Timer ExpiredがあるNOTIFICATIONメッセージを送ります。
- sets the ConnectRetryTimer to zero,
- ゼロにConnectRetryTimerを設定します。
- releases all BGP resources,
- すべてのBGPリソースを発表します。
- drops the TCP connection,
- TCP接続を下げます。
- increments the ConnectRetryCounter by 1,
- ConnectRetryCounterを1つ増加します。
- (optionally) performs peer oscillation damping if the
DampPeerOscillations attribute is set to TRUE, and
- そしてDampPeerOscillations属性がTRUEに設定されるなら(任意に)同輩振動湿気を実行する。
- changes its state to Idle.
- 状態をIdleに変えます。
If the local system receives a KeepaliveTimer_Expires event (Event
11), the local system:
ローカルシステムがKeepaliveTimer_Expiresイベント(イベント11)、ローカルシステムを受け取るなら:
- sends a KEEPALIVE message,
- KEEPALIVEメッセージを送ります。
- restarts the KeepaliveTimer, and
- そしてKeepaliveTimerを再開する。
- remains in the OpenConfirmed state.
- OpenConfirmed状態の残り。
In the event of a TcpConnection_Valid event (Event 14), or the
success of a TCP connection (Event 16 or Event 17) while in
OpenConfirm, the local system needs to track the second
connection.
TcpConnection_Validイベント(イベント14)、またはローカルシステムが、OpenConfirmで必要がある間のTCP接続(イベント16かEvent17)の成功の場合、2番目の接続を追跡してください。
If a TCP connection is attempted with an invalid port (Event 15),
the local system will ignore the second connection attempt.
TCP接続が無効のポート(イベント15)で試みられると、ローカルシステムは2番目の接続試みを無視するでしょう。
If the local system receives a TcpConnectionFails event (Event 18)
from the underlying TCP or a NOTIFICATION message (Event 25), the
local system:
ローカルシステムは基本的なTCPからTcpConnectionFailsイベント(イベント18)を受けるか、そして、NOTIFICATIONメッセージ(イベント25)、ローカルシステム:
- sets the ConnectRetryTimer to zero,
- ゼロにConnectRetryTimerを設定します。
- releases all BGP resources,
- すべてのBGPリソースを発表します。
- drops the TCP connection,
- TCP接続を下げます。
- increments the ConnectRetryCounter by 1,
- ConnectRetryCounterを1つ増加します。
- (optionally) performs peer oscillation damping if the
DampPeerOscillations attribute is set to TRUE, and
- そしてDampPeerOscillations属性がTRUEに設定されるなら(任意に)同輩振動湿気を実行する。
Rekhter, et al. Standards Track [Page 68] RFC 4271 BGP-4 January 2006
Rekhter、他 標準化過程[68ページ]RFC4271BGP-2006年1月4日
- changes its state to Idle.
- 状態をIdleに変えます。
If the local system receives a NOTIFICATION message with a version
error (NotifMsgVerErr (Event 24)), the local system:
ローカルシステムがバージョン誤り(NotifMsgVerErr(イベント24))、ローカルシステムでNOTIFICATIONメッセージを受け取るなら:
- sets the ConnectRetryTimer to zero,
- ゼロにConnectRetryTimerを設定します。
- releases all BGP resources,
- すべてのBGPリソースを発表します。
- drops the TCP connection, and
- そしてTCP接続を下げる。
- changes its state to Idle.
- 状態をIdleに変えます。
If the local system receives a valid OPEN message (BGPOpen (Event
19)), the collision detect function is processed per Section 6.8.
If this connection is to be dropped due to connection collision,
the local system:
ローカルシステムが有効なオープンメッセージ(BGPOpen(イベント19))を受け取るなら、衝突は機能を検出します。セクション6.8単位で処理されます。 この接続が接続衝突、ローカルシステムのため下げられるつもりであるなら:
- sends a NOTIFICATION with a Cease,
- Ceaseと共に通知書を送っています。
- sets the ConnectRetryTimer to zero,
- ゼロにConnectRetryTimerを設定します。
- releases all BGP resources,
- すべてのBGPリソースを発表します。
- drops the TCP connection (send TCP FIN),
- TCP接続(TCP FINを送る)を下げます。
- increments the ConnectRetryCounter by 1,
- ConnectRetryCounterを1つ増加します。
- (optionally) performs peer oscillation damping if the
DampPeerOscillations attribute is set to TRUE, and
- そしてDampPeerOscillations属性がTRUEに設定されるなら(任意に)同輩振動湿気を実行する。
- changes its state to Idle.
- 状態をIdleに変えます。
If an OPEN message is received, all fields are checked for
correctness. If the BGP message header checking (BGPHeaderErr
(Event 21)) or OPEN message checking detects an error (see Section
6.2) (BGPOpenMsgErr (Event 22)), the local system:
オープンメッセージが受信されているなら、すべての分野が正当性がないかどうかチェックされます。 BGPメッセージであるなら、(BGPHeaderErr(イベント21))かオープンメッセージの照合をチェックするヘッダーが誤りを検出します(セクション6.2を見てください)(BGPOpenMsgErr(イベント22))、ローカルシステム:
- sends a NOTIFICATION message with the appropriate error code,
- 適切なエラーコードがあるNOTIFICATIONメッセージを送ります。
- sets the ConnectRetryTimer to zero,
- ゼロにConnectRetryTimerを設定します。
- releases all BGP resources,
- すべてのBGPリソースを発表します。
- drops the TCP connection,
- TCP接続を下げます。
- increments the ConnectRetryCounter by 1,
- ConnectRetryCounterを1つ増加します。
Rekhter, et al. Standards Track [Page 69] RFC 4271 BGP-4 January 2006
Rekhter、他 標準化過程[69ページ]RFC4271BGP-2006年1月4日
- (optionally) performs peer oscillation damping if the
DampPeerOscillations attribute is set to TRUE, and
- そしてDampPeerOscillations属性がTRUEに設定されるなら(任意に)同輩振動湿気を実行する。
- changes its state to Idle.
- 状態をIdleに変えます。
If, during the processing of another OPEN message, the BGP
implementation determines, by a means outside the scope of this
document, that a connection collision has occurred and this
connection is to be closed, the local system will issue an
OpenCollisionDump event (Event 23). When the local system
receives an OpenCollisionDump event (Event 23), the local system:
BGP実装が別のオープンメッセージの処理の間、接続衝突が起こって、この接続が閉店していることになっていることをこのドキュメントの範囲の外の手段で決定すると、ローカルシステムはOpenCollisionDumpイベント(イベント23)を発行するでしょう。 ローカルシステムがOpenCollisionDumpイベント(イベント23)、ローカルシステムを受け取るとき:
- sends a NOTIFICATION with a Cease,
- Ceaseと共に通知書を送っています。
- sets the ConnectRetryTimer to zero,
- ゼロにConnectRetryTimerを設定します。
- releases all BGP resources
- すべてのBGPリソースを発表します。
- drops the TCP connection,
- TCP接続を下げます。
- increments the ConnectRetryCounter by 1,
- ConnectRetryCounterを1つ増加します。
- (optionally) performs peer oscillation damping if the
DampPeerOscillations attribute is set to TRUE, and
- そしてDampPeerOscillations属性がTRUEに設定されるなら(任意に)同輩振動湿気を実行する。
- changes its state to Idle.
- 状態をIdleに変えます。
If the local system receives a KEEPALIVE message (KeepAliveMsg
(Event 26)), the local system:
ローカルシステムがKEEPALIVEメッセージ(KeepAliveMsg(イベント26))、ローカルシステムを受け取るなら:
- restarts the HoldTimer and
- そしてHoldTimerを再開する。
- changes its state to Established.
- 状態をEstablishedに変えます。
In response to any other event (Events 9, 12-13, 20, 27-28), the
local system:
いかなる他のイベント(イベント9、12-13、27-28の20)、ローカルシステムに対応して:
- sends a NOTIFICATION with a code of Finite State Machine
Error,
- Finite州Machine Errorのコードと共に通知書を送っています。
- sets the ConnectRetryTimer to zero,
- ゼロにConnectRetryTimerを設定します。
- releases all BGP resources,
- すべてのBGPリソースを発表します。
- drops the TCP connection,
- TCP接続を下げます。
- increments the ConnectRetryCounter by 1,
- ConnectRetryCounterを1つ増加します。
Rekhter, et al. Standards Track [Page 70] RFC 4271 BGP-4 January 2006
Rekhter、他 標準化過程[70ページ]RFC4271BGP-2006年1月4日
- (optionally) performs peer oscillation damping if the
DampPeerOscillations attribute is set to TRUE, and
- そしてDampPeerOscillations属性がTRUEに設定されるなら(任意に)同輩振動湿気を実行する。
- changes its state to Idle.
- 状態をIdleに変えます。
Established State:
設立された州:
In the Established state, the BGP FSM can exchange UPDATE,
NOTIFICATION, and KEEPALIVE messages with its peer.
Established状態では、BGP FSMは同輩と共にUPDATE、NOTIFICATION、およびKEEPALIVEメッセージを交換できます。
Any Start event (Events 1, 3-7) is ignored in the Established
state.
どんなStartイベント(3-7のイベント1)もEstablished状態で無視されます。
In response to a ManualStop event (initiated by an operator)
(Event 2), the local system:
ManualStopイベント(オペレータによって開始されます)(イベント2)、ローカルシステムに対応して:
- sends the NOTIFICATION message with a Cease,
- CeaseがあるNOTIFICATIONメッセージを送ります。
- sets the ConnectRetryTimer to zero,
- ゼロにConnectRetryTimerを設定します。
- deletes all routes associated with this connection,
- この接続に関連しているすべてのルートを削除します。
- releases BGP resources,
- BGPリソースを発表します。
- drops the TCP connection,
- TCP接続を落とします。
- sets the ConnectRetryCounter to zero, and
- そしてゼロにConnectRetryCounterを設定する。
- changes its state to Idle.
- 状態をIdleに変えます。
In response to an AutomaticStop event (Event 8), the local system:
AutomaticStop出来事(出来事8)、ローカルシステムに対応して:
- sends a NOTIFICATION with a Cease,
- Ceaseと共に通知書を送っています。
- sets the ConnectRetryTimer to zero
- ゼロにConnectRetryTimerを設定します。
- deletes all routes associated with this connection,
- この接続に関連しているすべてのルートを削除します。
- releases all BGP resources,
- すべてのBGPリソースを発表します。
- drops the TCP connection,
- TCP接続を落とします。
- increments the ConnectRetryCounter by 1,
- ConnectRetryCounterを1つ増加します。
- (optionally) performs peer oscillation damping if the
DampPeerOscillations attribute is set to TRUE, and
- そしてDampPeerOscillations属性がTRUEに設定されるなら(任意に)同輩振動湿気を実行する。
- changes its state to Idle.
- 状態をIdleに変えます。
Rekhter, et al. Standards Track [Page 71] RFC 4271 BGP-4 January 2006
Rekhter、他 標準化過程[71ページ]RFC4271BGP-2006年1月4日
One reason for an AutomaticStop event is: A BGP receives an UPDATE
messages with a number of prefixes for a given peer such that the
total prefixes received exceeds the maximum number of prefixes
configured. The local system automatically disconnects the peer.
AutomaticStop出来事の1つの理由は以下の通りです。 BGPが与えられた同輩のために多くの接頭語でUPDATEメッセージを受け取るので、接頭語が受け取った合計は構成された接頭語の最大数を超えています。 ローカルシステムは自動的に同輩を外します。
If the HoldTimer_Expires event occurs (Event 10), the local
system:
HoldTimer_Expires出来事は起こって(出来事10)、ローカルはシステムです:
- sends a NOTIFICATION message with the Error Code Hold Timer
Expired,
- Error Code Hold Timer ExpiredがあるNOTIFICATIONメッセージを送ります。
- sets the ConnectRetryTimer to zero,
- ゼロにConnectRetryTimerを設定します。
- releases all BGP resources,
- すべてのBGPリソースを発表します。
- drops the TCP connection,
- TCP接続を落とします。
- increments the ConnectRetryCounter by 1,
- ConnectRetryCounterを1つ増加します。
- (optionally) performs peer oscillation damping if the
DampPeerOscillations attribute is set to TRUE, and
- そしてDampPeerOscillations属性がTRUEに設定されるなら(任意に)同輩振動湿気を実行する。
- changes its state to Idle.
- 状態をIdleに変えます。
If the KeepaliveTimer_Expires event occurs (Event 11), the local
system:
KeepaliveTimer_Expires出来事は起こって(出来事11)、ローカルはシステムです:
- sends a KEEPALIVE message, and
- そしてKEEPALIVEメッセージを送る。
- restarts its KeepaliveTimer, unless the negotiated HoldTime
value is zero.
- 交渉されたHoldTime値がゼロでないならKeepaliveTimerを再開します。
Each time the local system sends a KEEPALIVE or UPDATE message, it
restarts its KeepaliveTimer, unless the negotiated HoldTime value
is zero.
ローカルシステムがKEEPALIVEかUPDATEメッセージを送る各回、KeepaliveTimerを再開します、交渉されたHoldTime値がゼロでないなら。
A TcpConnection_Valid (Event 14), received for a valid port, will
cause the second connection to be tracked.
有効なポートに受け取られたTcpConnection_Valid(出来事14)は2番目の接続を追跡させるでしょう。
An invalid TCP connection (Tcp_CR_Invalid event (Event 15)) will
be ignored.
無効のTCP接続(Tcp_CR_Invalid出来事(出来事15))は無視されるでしょう。
In response to an indication that the TCP connection is
successfully established (Event 16 or Event 17), the second
connection SHALL be tracked until it sends an OPEN message.
TCP接続は首尾よく確立されます(出来事16かEvent17)、2番目の接続SHALL。指示に対応したそれ、オープンメッセージを送るまで、追跡されます。
Rekhter, et al. Standards Track [Page 72] RFC 4271 BGP-4 January 2006
Rekhter、他 標準化過程[72ページ]RFC4271BGP-2006年1月4日
If a valid OPEN message (BGPOpen (Event 19)) is received, and if
the CollisionDetectEstablishedState optional attribute is TRUE,
the OPEN message will be checked to see if it collides (Section
6.8) with any other connection. If the BGP implementation
determines that this connection needs to be terminated, it will
process an OpenCollisionDump event (Event 23). If this connection
needs to be terminated, the local system:
有効なオープンメッセージ(BGPOpen(出来事19))が受信されていて、CollisionDetectEstablishedStateの任意の属性がTRUEであるなら、オープンメッセージは、それが接続にいかなる他のも衝突するかどうか(セクション6.8)確認するためにチェックされるでしょう。 BGP実現が、この接続が、終えられる必要を決定すると、それはOpenCollisionDump出来事(出来事23)を処理するでしょう。 これであるなら、接続は、終えられる必要があって、ローカルはシステムです:
- sends a NOTIFICATION with a Cease,
- Ceaseと共に通知書を送っています。
- sets the ConnectRetryTimer to zero,
- ゼロにConnectRetryTimerを設定します。
- deletes all routes associated with this connection,
- この接続に関連しているすべてのルートを削除します。
- releases all BGP resources,
- すべてのBGPリソースを発表します。
- drops the TCP connection,
- TCP接続を落とします。
- increments the ConnectRetryCounter by 1,
- ConnectRetryCounterを1つ増加します。
- (optionally) performs peer oscillation damping if the
DampPeerOscillations is set to TRUE, and
- そしてDampPeerOscillationsがTRUEに用意ができているなら(任意に)同輩振動湿気を実行する。
- changes its state to Idle.
- 状態をIdleに変えます。
If the local system receives a NOTIFICATION message (Event 24 or
Event 25) or a TcpConnectionFails (Event 18) from the underlying
TCP, the local system:
ローカルシステムはNOTIFICATIONメッセージ(出来事24かEvent25)を受け取るか、そして、基本的なTCP、ローカルシステムからのTcpConnectionFails(出来事18):
- sets the ConnectRetryTimer to zero,
- ゼロにConnectRetryTimerを設定します。
- deletes all routes associated with this connection,
- この接続に関連しているすべてのルートを削除します。
- releases all the BGP resources,
- すべてのBGPリソースを発表します。
- drops the TCP connection,
- TCP接続を落とします。
- increments the ConnectRetryCounter by 1,
- ConnectRetryCounterを1つ増加します。
- changes its state to Idle.
- 状態をIdleに変えます。
Rekhter, et al. Standards Track [Page 73] RFC 4271 BGP-4 January 2006
Rekhter、他 標準化過程[73ページ]RFC4271BGP-2006年1月4日
If the local system receives a KEEPALIVE message (Event 26), the
local system:
ローカルシステムがKEEPALIVEメッセージ(出来事26)、ローカルシステムを受け取るなら:
- restarts its HoldTimer, if the negotiated HoldTime value is
non-zero, and
- そして交渉されたHoldTime値が非ゼロであるならHoldTimerを再開する。
- remains in the Established state.
- Established状態の残り。
If the local system receives an UPDATE message (Event 27), the
local system:
ローカルシステムがUPDATEメッセージ(出来事27)、ローカルシステムを受け取るなら:
- processes the message,
- メッセージを処理します。
- restarts its HoldTimer, if the negotiated HoldTime value is
non-zero, and
- そして交渉されたHoldTime値が非ゼロであるならHoldTimerを再開する。
- remains in the Established state.
- Established状態の残り。
If the local system receives an UPDATE message, and the UPDATE
message error handling procedure (see Section 6.3) detects an
error (Event 28), the local system:
ローカルシステムが受信されるなら、UPDATEは通信します、そして、UPDATEメッセージエラー処理手順(セクション6.3を見る)は誤り(出来事28)を検出します、ローカルシステム:
- sends a NOTIFICATION message with an Update error,
- Update誤りと共にNOTIFICATIONメッセージを送ります。
- sets the ConnectRetryTimer to zero,
- ゼロにConnectRetryTimerを設定します。
- deletes all routes associated with this connection,
- この接続に関連しているすべてのルートを削除します。
- releases all BGP resources,
- すべてのBGPリソースを発表します。
- drops the TCP connection,
- TCP接続を落とします。
- increments the ConnectRetryCounter by 1,
- ConnectRetryCounterを1つ増加します。
- (optionally) performs peer oscillation damping if the
DampPeerOscillations attribute is set to TRUE, and
- そしてDampPeerOscillations属性がTRUEに設定されるなら(任意に)同輩振動湿気を実行する。
- changes its state to Idle.
- 状態をIdleに変えます。
In response to any other event (Events 9, 12-13, 20-22), the local
system:
いかなる他の出来事(12-13と、20-22の出来事9)、ローカルシステムに対応して:
- sends a NOTIFICATION message with the Error Code Finite State
Machine Error,
- Error Code Finite州Machine ErrorがあるNOTIFICATIONメッセージを送ります。
- deletes all routes associated with this connection,
- この接続に関連しているすべてのルートを削除します。
- sets the ConnectRetryTimer to zero,
- ゼロにConnectRetryTimerを設定します。
Rekhter, et al. Standards Track [Page 74] RFC 4271 BGP-4 January 2006
Rekhter、他 標準化過程[74ページ]RFC4271BGP-2006年1月4日
- releases all BGP resources,
- すべてのBGPリソースを発表します。
- drops the TCP connection,
- TCP接続を落とします。
- increments the ConnectRetryCounter by 1,
- ConnectRetryCounterを1つ増加します。
- (optionally) performs peer oscillation damping if the
DampPeerOscillations attribute is set to TRUE, and
- そしてDampPeerOscillations属性がTRUEに設定されるなら(任意に)同輩振動湿気を実行する。
- changes its state to Idle.
- 状態をIdleに変えます。
9. UPDATE Message Handling
9. アップデートメッセージハンドリング
An UPDATE message may be received only in the Established state. Receiving an UPDATE message in any other state is an error. When an UPDATE message is received, each field is checked for validity, as specified in Section 6.3.
Established状態だけにUPDATEメッセージを受け取るかもしれません。 いかなる他の状態にも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) are contained in this field, SHALL be removed from the Adj-RIB-In. This BGP speaker SHALL run its Decision Process because the previously advertised route is no longer available for use.
SHALL、UPDATEメッセージが非人影のないWITHDRAWN ROUTES分野、以前に広告を出したルートを含んでいるなら、この分野にだれの目的地を保管しているか(IP接頭語として、言い表されます)。中のAdj-RIBから、取り除きます。 以前に広告を出したルートがもう使用に利用可能でないので、このBGPスピーカーSHALLはDecision Processを走らせます。
If the UPDATE message contains a feasible route, the Adj-RIB-In will be updated with this route as follows: if the NLRI of the new route is identical to the one the route currently has 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. Otherwise, if the Adj-RIB-In has no route with NLRI identical to the new route, the new route SHALL be placed in the Adj-RIB-In.
UPDATEメッセージが可能なルートを含んでいると、このルートは以下の通りで中のAdj-RIBをアップデートするでしょう: 新しいルートのNLRIがルートが現在中のAdj- RIBに格納したものと同じであるなら、新しいルートSHALLは中のAdj- RIBの、より古いルートを置き換えます、その結果、それとなく、サービスから、より古いルートを引っ込めます。 さもなければ、中のAdj-RIBにルートが全くないなら、新しいルート、新しいルートSHALLと同じNLRIと共に、中のAdj-RIBに置かれてください。
Once the BGP speaker updates the Adj-RIB-In, the speaker SHALL run its Decision Process.
BGPスピーカーがいったん中のAdj-RIBをアップデートすると、スピーカーSHALLはDecision Processを走らせます。
Rekhter, et al. Standards Track [Page 75] RFC 4271 BGP-4 January 2006
Rekhter、他 標準化過程[75ページ]RFC4271BGP-2006年1月4日
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-RIBs-In. The output of the Decision Process is the set of routes that will be advertised to peers; the selected routes will be stored in the local speaker's Adj-RIBs-Out, according to policy.
Decision Processは、地方のPolicy Information基地(PIB)の中の方針を中のAdj-RIBsに格納されたルートに適用することによって、その後の広告のためのルートを選択します。 Decision Processの出力は同輩に広告に掲載されているルートのセットです。 方針に応じて、選択されたルートは外の地元のスピーカーのAdj-RIBsに格納されるでしょう。
The BGP Decision Process described here is conceptual, and does not have to be implemented precisely as described, as long as the implementations support the described functionality and they exhibit the same externally visible behavior.
ここで説明されたBGP Decision Processは概念的であり、まさに説明されるように実行される必要はありません、実現が説明された機能性を支持して、同じ外部的に目に見える振舞いを示す限り。
The selection process is formalized by defining a function that takes the attribute of a given route as an argument and returns either (a) a non-negative integer denoting the degree of preference for the route, or (b) a value denoting that this route is ineligible to be installed in Loc-RIB and will be excluded from the next phase of route selection.
選択の過程は、議論として与えられたルートの属性をみなして、(a) ルートのための好みの度合いを指示する非負の整数か(b) このルートがLoc-RIBにインストールされるのにおいて不適格であることを指示する値のどちらかを返す機能を定義することによって正式にされて、ルート選択の次のフェーズから除かれるでしょう。
The function that calculates the degree of preference for a given route SHALL NOT use any of the following as its inputs: the existence of other routes, the non-existence of other routes, or the path attributes of other routes. Route selection then consists of the 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.
与えられたルートSHALL NOTのために好みの度合いについて計算する機能は入力として以下のどれかを使用します: 他のルートの存在、他のルートの非存在、または他のルートの経路属性。 そして、ルート選択は最も高度の好みによるものの選択があとに続いたそれぞれの可能なルートに選択関数の度合いの個々の適用から成ります。
The Decision Process operates on routes contained in the Adj-RIBs-In, and is responsible for:
Decision Processは中のAdj-RIBsに含まれたルートを作動させて、以下に責任があります。
- selection of routes to be used locally by the speaker
- スピーカーによって局所的に使用されるべきルートの品揃え
- selection of routes to be advertised to other BGP peers
- 他の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 peer.
a) フェーズ1は同輩から受け取られた各ルートのための好みの度合いについて計算するのに原因となります。
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 Loc-RIB.
b) フェーズ2はフェーズ1の完成のときに呼び出されます。 それはそれぞれの異なった目的地へのすべての利用可能なそれらから最も良いルートを選んで、それぞれの選ばれたルートをLoc-RIBにインストールするのに責任があります。
Rekhter, et al. Standards Track [Page 76] RFC 4271 BGP-4 January 2006
Rekhter、他 標準化過程[76ページ]RFC4271BGP-2006年1月4日
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, according to the policies contained in the PIB. Route
aggregation and information reduction can optionally be
performed within this phase.
c) Loc-RIBが変更された後にフェーズ3は呼び出されます。 それはPIBに含まれた方針に従ってLoc-RIBのルートを各同輩に広めるのに責任があります。 このフェーズの中で任意にルート集合と情報減少を実行できます。
9.1.1. Phase 1: Calculation of Degree of Preference
9.1.1. フェーズ1: 好みの度合いの計算
The Phase 1 decision function is invoked whenever the local BGP speaker receives, from a peer, an UPDATE message that advertises a new route, a replacement route, or withdrawn routes.
Phaseの1つの決定の機能は地元のBGPスピーカーが同輩からUPDATEメッセージを受け取るときはいつも、呼び出されて、それが新しいルートの広告を出します、交換ルートの、または、よそよそしいルートということです。
The Phase 1 decision function is a separate process,f which completes when it has no further work to do.
Phase1決定関数は別々の過程、いつを完成するfです。それはこれ以上仕事がありません。
The Phase 1 decision function locks an Adj-RIB-In prior to operating on any route contained within it, and unlocks it after operating on all new or unfeasible routes contained within it.
Phase1決定関数は、それの中に含まれたどんなルートも作動させる前に中のAdj-RIBをロックして、それの中に含まれたすべての新しいか実行不可能なルートを作動させた後に、それをアンロックします。
For each newly received or replacement feasible route, the local BGP speaker determines a degree of preference as follows:
新たに受け取られたそれぞれか交換の可能なルートと、地元のBGPスピーカーは以下の1段階の好みを決定します:
If the route is learned from an internal peer, either the value of
the LOCAL_PREF attribute is taken as the degree of preference, or
the local system computes the degree of preference of the route
based on preconfigured policy information. Note that the latter
may result in formation of persistent routing loops.
ルートが内部の同輩から学習されるなら、LOCAL_PREF属性の値が好みの度合いとしてみなされるか、またはローカルシステムはあらかじめ設定された方針情報に基づくルートの好みの度合いを計算します。 後者がしつこいルーティング輪の構成をもたらすかもしれないことに注意してください。
If the route is learned from an external peer, then the local BGP
speaker computes the degree of preference based on preconfigured
policy information. If the return value indicates the route is
ineligible, the route MAY NOT serve as an input to the next phase
of route selection; otherwise, the return value MUST be used as
the LOCAL_PREF value in any IBGP readvertisement.
ルートが外部の同輩から学習されるなら、地元のBGPスピーカーはあらかじめ設定された方針情報に基づく好みの度合いを計算します。 リターン値が、ルートが不適格であることを示すなら、ルートは入力としてルート選択の次のフェーズに機能しないかもしれません。 さもなければ、LOCAL_PREFがどんなIBGP readvertisementでも評価するようにリターン値は使用されているに違いありません。
The exact nature of this policy information, and the computation
involved, is a local matter.
この方針情報の正確な本質、およびかかわった計算は地域にかかわる事柄です。
9.1.2. Phase 2: Route Selection
9.1.2. フェーズ2: ルート選択
The Phase 2 decision function is 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 considers all routes that are eligible in the Adj-RIBs-In.
Phase2決定関数はPhase1の完成のときに呼び出されます。 Phase2機能は別々の過程であり、どれがいつを完成するか。それはこれ以上仕事がありません。 2が処理するPhaseはすべての中のAdj-RIBsで適任のルートを考えます。
Rekhter, et al. Standards Track [Page 77] RFC 4271 BGP-4 January 2006
Rekhter、他 標準化過程[77ページ]RFC4271BGP-2006年1月4日
The Phase 2 decision function is blocked from running while the Phase 3 decision function is in process. The Phase 2 function locks all Adj-RIBs-In prior to commencing its function, and unlocks them on completion.
Phase2決定関数はPhase3決定関数が過程にある間、走るのが妨げられます。 Phase2機能は、機能を始める前に中のすべてのAdj-RIBsをロックして、完成のときに彼らをアンロックします。
If the NEXT_HOP attribute of a BGP route depicts an address that is not resolvable, or if it would become unresolvable if the route was installed in the routing table, the BGP route MUST be excluded from the Phase 2 decision function.
BGPルートのネクスト_HOP属性が溶解性でないアドレスについて表現するか、またはルートが経路指定テーブルにインストールされるなら「非-溶解性」になるなら、Phase2決定関数からBGPルートを除かなければなりません。
If the AS_PATH attribute of a BGP route contains an AS loop, the BGP route should be excluded from the Phase 2 decision function. AS loop detection is done by scanning the full AS path (as specified in the AS_PATH attribute), and checking that the autonomous system number of the local system does not appear in the AS path. Operations of a BGP speaker that is configured to accept routes with its own autonomous system number in the AS path are outside the scope of this document.
BGPルートのAS_PATH属性がAS輪を含んでいるなら、BGPルートはPhase2決定関数から除かれるべきです。 完全なAS経路(AS_PATH属性で指定されるように)をスキャンして、ローカルシステムの自律システム番号がAS経路に現れないのをチェックすることによって、AS輪の検出をします。 このドキュメントの範囲の外にそれ自身の自律システム番号がAS経路にある状態でルートを受け入れるために構成されるBGPスピーカーの操作があります。
It is critical that BGP speakers within an AS do not make conflicting decisions regarding route selection that would cause forwarding loops to occur.
起こるのはASの中のBGPスピーカーが推進を引き起こすルート選択に関する闘争決定を輪にしないのが重要です。
For each set of destinations for which a feasible route exists in the Adj-RIBs-In, the local BGP speaker identifies 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 Section 9.1.2.2.
c)は壊れている規則がセクション9.1.2で.2に指定したPhase2繋がりの結果、選択されます。
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. When the new BGP route is installed in the Routing Table, care must be taken to ensure that existing routes to the same destination that are now considered invalid are removed from the Routing Table. Whether the new BGP route replaces an existing non-BGP route in the Routing Table depends on the policy configured on the BGP speaker.
次に、地方のスピーカーSHALLはそのルートをLoc-RIBにインストールします、現在Loc-RIBで開催されているのと同じ目的地にどんなルートも置き換えて。 新しいBGPルートがルート設定Tableにインストールされるとき、同じ目的地への現在無効であると考えられる既存のルートがルート設定Tableから取り外されるのを保証するために注意しなければなりません。 新しいBGPルートがルート設定Tableにおける既存の非BGPルートを置き換えるかどうかがBGPスピーカーの上で構成された方針によります。
The local speaker MUST determine the immediate next-hop address from the NEXT_HOP attribute of the selected route (see Section 5.1.3). If either the immediate next-hop or the IGP cost to the NEXT_HOP (where the NEXT_HOP is resolved through an IGP route) changes, Phase 2 Route Selection MUST be performed again.
地元のスピーカーは選択されたルートのネクスト_HOP属性からの即座の次のホップアドレスを決定しなければなりません(セクション5.1.3を見てください)。 ネクスト_HOP(ネクスト_HOPがIGPルートで決議されているところ)が即座の次のホップかIGPのどちらかに変化を費やすなら、再びPhase2Route Selectionを実行しなければなりません。
Rekhter, et al. Standards Track [Page 78] RFC 4271 BGP-4 January 2006
Rekhter、他 標準化過程[78ページ]RFC4271BGP-2006年1月4日
Notice that even though BGP routes do not have to be installed in the Routing Table with the immediate next-hop(s), implementations MUST take care that, before any packets are forwarded along a BGP route, its associated NEXT_HOP address is resolved to the immediate (directly connected) next-hop address, and that this address (or multiple addresses) is finally used for actual packet forwarding.
BGPルートが即座の次のホップでルート設定Tableにインストールされる必要はありませんが、実現が、BGPルートに沿ってどんなパケットも進める前に即座(直接接続される)の次のホップアドレスに関連ネクスト_HOPアドレスを決議することに注意しなければならなくて、このアドレス(または、複数のアドレス)が実際のパケット推進に最終的に使用されるのに注意してください。
Unresolvable routes SHALL be removed from the Loc-RIB and the routing table. However, corresponding unresolvable routes SHOULD be kept in the Adj-RIBs-In (in case they become resolvable).
UnresolvableはSHALLを発送します。Loc-RIBと経路指定テーブルから、取り除きます。 しかしながら、対応する「非-溶解性」は保たれたコネが中のAdj-RIBs(彼らが溶解性になるといけないので)であったならSHOULDを発送します。
9.1.2.1. Route Resolvability Condition
9.1.2.1. ルートResolvability状態
As indicated in Section 9.1.2, BGP speakers SHOULD exclude unresolvable routes from the Phase 2 decision. This ensures that only valid routes are installed in Loc-RIB and the Routing Table.
セクション9.1.2にみられるように、BGPスピーカーSHOULDはPhase2決定に「非-溶解性」ルートを入れないようにします。 これは、有効なルートだけがLoc-RIBとルート設定Tableにインストールされるのを確実にします。
The route resolvability condition is defined as follows:
ルート「再-解決可能性」状態は以下の通り定義されます:
1) A route Rte1, referencing only the intermediate network
address, is considered resolvable if the Routing Table contains
at least one resolvable route Rte2 that matches Rte1's
intermediate network address and is not recursively resolved
(directly or indirectly) through Rte1. If multiple matching
routes are available, only the longest matching route SHOULD be
considered.
1) ルートRte1は中間ネットワークアドレスだけに参照をつけて、ルート設定TableがRte1の中間ネットワークアドレスに合っている少なくとも1溶解性のルートRte2を含んでいるなら溶解性であると考えられて、Rte1を通して再帰的に決議されていません(直接か間接的に)。 複数の合っているルートが利用可能であるなら、考えられて、最も長いマッチングだけがSHOULDを発送します。
2) Routes referencing interfaces (with or without intermediate
addresses) are considered resolvable if the state of the
referenced interface is up and if IP processing is enabled on
this interface.
2) 参照をつけられたインタフェースの州が上がって、IP処理がこのインタフェースで可能にされるなら、インタフェース(中間的アドレスのあるなしにかかわらず)に参照をつけるルートは溶解性であると考えられます。
BGP routes do not refer to interfaces, but can be resolved through the routes in the Routing Table that can be of both types (those that specify interfaces or those that do not). IGP routes and routes to directly connected networks are expected to specify the outbound interface. Static routes can specify the outbound interface, the intermediate address, or both.
BGPルートをインタフェースについて言及しませんが、両方のタイプ(インタフェースを指定するものかそうしないそれら)にはあることができるルート設定Tableにおけるルートで決議できます。 直接接続されたネットワークへのIGPルートとルートが外国行きのインタフェースを指定すると予想されます。 スタティックルートは外国行きのインタフェース、中間的アドレス、または両方を指定できます。
Note that a BGP route is considered unresolvable in a situation where the BGP speaker's Routing Table contains no route matching the BGP route's NEXT_HOP. Mutually recursive routes (routes resolving each other or themselves) also fail the resolvability check.
BGPルートがBGPルートのネクスト_HOPを合わせながらBGPスピーカーのルート設定Tableがルートを全く含まないところで状況で「非-溶解性」であると考えられることに注意してください。 また、互いに再帰的なルート(決議するルート)は「再-解決可能性」チェックに失敗します。
It is also important that implementations do not consider feasible routes that would become unresolvable if they were installed in the Routing Table, even if their NEXT_HOPs are resolvable using the current contents of the Routing Table (an example of such routes
また、実現がそれらがルート設定Tableにインストールされるなら「非-溶解性」になる可能なルートを考えないのも、重要です、それらのネクスト_HOPsがルート設定Tableの現在のコンテンツを使用することで溶解性であっても(そのようなルートに関する例
Rekhter, et al. Standards Track [Page 79] RFC 4271 BGP-4 January 2006
Rekhter、他 標準化過程[79ページ]RFC4271BGP-2006年1月4日
would be mutually recursive routes). This check ensures that a BGP speaker does not install routes in the Routing Table that will be removed and not used by the speaker. Therefore, in addition to local Routing Table stability, this check also improves behavior of the protocol in the network.
互いに再帰的なルートであるだろう、) このチェックは、BGPスピーカーが取り外されて、スピーカーによって使用されないルート設定Tableにルートをインストールしないのを確実にします。 したがって、また、地方のルート設定Tableの安定性に加えて、このチェックはネットワークにおける、プロトコルの振舞いを改良します。
Whenever a BGP speaker identifies a route that fails the resolvability check because of mutual recursion, an error message SHOULD be logged.
BGPスピーカーが互いの再帰で「再-解決可能性」チェックに失敗するルートを特定して、エラーメッセージがSHOULDであるときはいつも、登録されてください。
9.1.2.2. Breaking Ties (Phase 2)
9.1.2.2. 壊れている結びつき(フェーズ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 routes with the same degrees of preference, both those received from internal peers, and those received from external peers.
中のAdj-RIBsでは、BGPスピーカーは同じ度の好みを持っている数個のルートを同じ目的地に持っているかもしれません。 地元のスピーカーは関連Loc-RIBでの包含のためのこれらのルートの1つしか選択できません。 内部の同輩から受け取られたものとそれらの両方が、外部の同輩から地元のスピーカーが同じ度の好みがあるすべてのルートを考えるのを受けました。
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 NEXT_HOP attribute of the route, and follow the same route selection algorithm.
以下の繋がりを壊す手順は、自律システムの中のすべてのBGPスピーカーがそれぞれの候補ルートにルートのネクスト_HOP属性によって表現されたアドレスに経路(内部の距離)の費用を確かめて、同じルート選択アルゴリズムに従うことができると仮定します。
The tie-breaking algorithm begins by considering all equally preferable routes to the same destination, and then selects routes to be removed from consideration. The algorithm terminates as soon as only one route remains in consideration. The criteria MUST be applied in the order specified.
繋がりを壊すアルゴリズムは、すべての等しく望ましいルートを同じ目的地と考えることによって始まって、次に、ルートが考慮から取り外されるのを選択します。 1つのルートだけが考慮に残っているとすぐに、アルゴリズムは終わります。 指定されたオーダーで評価基準を適用しなければなりません。
Several of the criteria are described using pseudo-code. Note that the pseudo-code shown was chosen for clarity, not efficiency. It is not intended to specify any particular implementation. BGP implementations MAY use any algorithm that produces the same results as those described here.
いくつかの評価基準が、中間コードを使用することで説明されます。 示された中間コードが効率ではなく、明快に選ばれたことに注意してください。 それがどんな特定の実現も指定することを意図しません。 BGP実現はここで説明されたものと同じ結果を生むどんなアルゴリズムも使用するかもしれません。
a) Remove from consideration all routes that are not tied for
having the smallest number of AS numbers present in their
AS_PATH attributes. Note that when counting this number, an
AS_SET counts as 1, no matter how many ASes are in the set.
a) 考慮から、それらのAS_PATH属性における現在のAS番号の最も少ない数を持つために結ばれないすべてのルートを取り外してください。 この数を数えるとき、セットにいくつのASesがあってもAS_SETが1にみなすことに注意してください。
b) Remove from consideration all routes that are not tied for
having the lowest Origin number in their Origin attribute.
b) 考慮から、それらのOrigin属性における最も下位のOrigin番号を持つために結ばれないすべてのルートを取り外してください。
Rekhter, et al. Standards Track [Page 80] RFC 4271 BGP-4 January 2006
Rekhter、他 標準化過程[80ページ]RFC4271BGP-2006年1月4日
c) Remove from consideration routes with less-preferred
MULTI_EXIT_DISC attributes. MULTI_EXIT_DISC is only comparable
between routes learned from the same neighboring AS (the
neighboring AS is determined from the AS_PATH attribute).
Routes that do not have the MULTI_EXIT_DISC attribute are
considered to have the lowest possible MULTI_EXIT_DISC value.
c) それほど都合のよくないMULTI_EXIT_DISC属性がある考慮ルートから、取り外してください。 MULTI_EXIT_DISCは同じ隣接しているASから学習されたルートの間で匹敵しているだけです(隣接しているASはAS_PATH属性から断固としています)。 MULTI_EXIT_DISC属性を持っていないルートが可能な限り低いMULTI_EXIT_DISC価値を持っていると考えられます。
This is also described in the following procedure:
また、これは以下の手順で説明されます:
for m = all routes still under consideration
for n = all routes still under consideration
if (neighborAS(m) == neighborAS(n)) and (MED(n) < MED(m))
remove route m from consideration
そして、すべてがまだ考慮の下のすべてのn=ルートにまだ考慮で発送するm=、(neighborAS(m)=neighborAS(n))、(MED(n)<MED(m))は考慮からルートmを取り除きます。
In the pseudo-code above, MED(n) is a function that returns the
value of route n's MULTI_EXIT_DISC attribute. If route n has
no MULTI_EXIT_DISC attribute, the function returns the lowest
possible MULTI_EXIT_DISC value (i.e., 0).
中間コードでは、MED(n)は上では、nのMULTI_EXIT_DISC属性をルートの値に返す機能です。 ルートnにMULTI_EXIT_DISC属性が全くないなら、機能は_EXIT_DISC値(すなわち、0)を可能な限り低いMULTIに返します。
Similarly, neighborAS(n) is a function that returns the
neighbor AS from which the route was received. If the route is
learned via IBGP, and the other IBGP speaker didn't originate
the route, it is the neighbor AS from which the other IBGP
speaker learned the route. If the route is learned via IBGP,
and the other IBGP speaker either (a) originated the route, or
(b) created the route by aggregation and the AS_PATH attribute
of the aggregate route is either empty or begins with an
AS_SET, it is the local AS.
同様に、neighborAS(n)はルートが受け取られた隣人ASを返す機能です。 ルートがIBGPを通して学習されて、もう片方のIBGPスピーカーがルートを溯源しなかったなら、それはもう片方のIBGPスピーカーがルートを学んだ隣人ASです。 (b)は集合でルートを作成しました、そして、集合ルートのAS_PATH属性は、空であるか、またはAS_SETと共に始まります、そして、ルートが学習されるなら、IBGP、およびもう片方のIBGPスピーカーを通したどちらかの(a)がルートを溯源したか、それは地方のASです。
If a MULTI_EXIT_DISC attribute is removed before re-advertising
a route into IBGP, then comparison based on the received EBGP
MULTI_EXIT_DISC attribute MAY still be performed. If an
implementation chooses to remove MULTI_EXIT_DISC, then the
optional comparison on MULTI_EXIT_DISC, if performed, MUST be
performed only among EBGP-learned routes. The best EBGP-
learned route may then be compared with IBGP-learned routes
after the removal of the MULTI_EXIT_DISC attribute. If
MULTI_EXIT_DISC is removed from a subset of EBGP-learned
routes, and the selected "best" EBGP-learned route will not
have MULTI_EXIT_DISC removed, then the MULTI_EXIT_DISC must be
used in the comparison with IBGP-learned routes. For IBGP-
learned routes, the MULTI_EXIT_DISC MUST be used in route
comparisons that reach this step in the Decision Process.
Including the MULTI_EXIT_DISC of an EBGP-learned route in the
comparison with an IBGP-learned route, then removing the
MULTI_EXIT_DISC attribute, and advertising the route has been
proven to cause route loops.
IBGPにルートの再広告を出す前にMULTI_EXIT_DISC属性を取り除くなら、まだ容認されたEBGP MULTI_EXIT_DISC属性に基づく比較を実行しているかもしれません。 実現が、MULTI_EXIT_DISCを取り外すのを選ぶなら、実行されるなら、EBGPが学術的なルートだけの中でMULTI_EXIT_DISCにおける任意の比較を実行しなければなりません。 そして、最も良いEBGP学術的ルートはMULTI_EXIT_DISC属性の取り外しの後にIBGPが学術的なルートにたとえられるかもしれません。 MULTI_EXIT_DISCがEBGPが学術的なルートの部分集合から取り外されて、選択されたEBGPが学術的な「最も良い」ルートがDISCが取り外したMULTI_EXIT_を持たないなら、IBGPが学術的なルートとの比較にMULTI_EXIT_DISCを使用しなければなりません。 IBGPが、ルート、MULTI_EXIT_DISC MUSTがDecision Processのこのステップに達するルート比較に使用されることを学んだので。 ルート輪を引き起こす_IBGPが学術的なルートとの次に、MULTI_EXIT_DISC属性を取り除いて、ルートの広告を出す比較におけるEBGPが学術的なルートのDISCが立証されたMULTI_EXITを含んでいます。
Rekhter, et al. Standards Track [Page 81] RFC 4271 BGP-4 January 2006
Rekhter、他 標準化過程[81ページ]RFC4271BGP-2006年1月4日
d) If at least one of the candidate routes was received via EBGP,
remove from consideration all routes that were received via
IBGP.
d) EBGPを通して少なくとも候補ルートの1つを受け取ったなら、考慮から、IBGPを通して受け取られたすべてのルートを取り外してください。
e) Remove from consideration any routes with less-preferred
interior cost. The interior cost of a route is determined by
calculating the metric to the NEXT_HOP for the route using the
Routing Table. If the NEXT_HOP hop for a route is reachable,
but no cost can be determined, then this step should be skipped
(equivalently, consider all routes to have equal costs).
e) 考慮から、それほど都合のよくない内部の費用があるあらゆるルートを取り外してください。 ルートの内部の費用は、ルート設定Tableを使用することで_ネクストHOPへのメートル法についてルートに計算することによって、決定します。 HOPがルートに飛び越すネクスト_が届いていますが、費用が全く決定できないなら、このステップはサボられるべきです(同等に、すべてのルートには等しいコストがあると考えてください)。
This is also described in the following procedure.
また、これは以下の手順で説明されます。
for m = all routes still under consideration
for n = all routes in still under consideration
if (cost(n) is lower than cost(m))
remove m from consideration
すべてが考慮の下のまだすべてのn=ルートのためにまだ考慮で発送するm=、(費用(n)が考慮から費用(m))が取り外されるより低いm離れたところにあります。
In the pseudo-code above, cost(n) is a function that returns
the cost of the path (interior distance) to the address given
in the NEXT_HOP attribute of the route.
中間コードでは、費用(n)は上では、ルートのネクスト_HOP属性で与えられたアドレスに経路(内部の距離)の費用を返す機能です。
f) Remove from consideration all routes other than the route that
was advertised by the BGP speaker with the lowest BGP
Identifier value.
f) 考慮から、最も低いBGP Identifier値でBGPスピーカーによって広告に掲載されたルート以外のすべてのルートを取り外してください。
g) Prefer the route received from the lowest peer address.
g) 最も低い同輩アドレスから受け取られたルートを好んでください。
9.1.3. Phase 3: Route Dissemination
9.1.3. フェーズ3: ルート普及
The Phase 3 decision function is invoked on completion of Phase 2, or when any of the following events occur:
Phase3決定関数はPhase2の完成のときに呼び出されて、以下の出来事のどれかがいつ起こるかをそうされます:
a) when routes in the 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 connection has been established
新しいBGPスピーカー接続であるときに、c)は設立されました。
The Phase 3 function is a separate process that completes when it has no further work to do. The Phase 3 Routing Decision function is blocked from running while the Phase 2 decision function is in process.
これ以上仕事がないとき、Phase3機能はそれが完了する別々の過程です。 Phase3ルート設定Decision機能はPhase2決定関数が過程にある間、走るのが妨げられます。
All routes in the Loc-RIB are processed into Adj-RIBs-Out according to configured policy. This policy MAY exclude a route in the Loc-RIB from being installed in a particular Adj-RIB-Out. A route SHALL NOT
構成された方針によると、Loc-RIBのすべてのルートが外のAdj-RIBsに処理されます。 この方針は外の特定のAdj-RIBにインストールされるのにLoc-RIBのルートを入れないようにするかもしれません。 ルートSHALL NOT
Rekhter, et al. Standards Track [Page 82] RFC 4271 BGP-4 January 2006
Rekhter、他 標準化過程[82ページ]RFC4271BGP-2006年1月4日
be installed in the Adj-Rib-Out unless the destination, and NEXT_HOP described by this route, may be forwarded appropriately by the Routing Table. If a route in Loc-RIB is excluded from a particular Adj-RIB-Out, the previously advertised route in that Adj-RIB-Out MUST be withdrawn from service by means of an UPDATE message (see 9.2).
目的地、およびこのルートで説明されたネクスト_HOPがルート設定Tableによって適切に進められないかもしれないなら、Adjあばら骨アウトにインストールされてください。 Loc-RIBのルートが外の特定のAdj-RIBから除かれるなら、UPDATEメッセージによってサービスから外のそのAdj-RIBの以前に広告を出したルートを引っ込めなければなりません(9.2を見てください)。
Route aggregation and information reduction techniques (see Section 9.2.2.1) may optionally be applied.
セクション9.2を見てください。集合と情報減少のテクニックを発送してください、(.2 適用されていて、.1は)任意にそうしてもよいです。
Any local policy that results in routes being added to an Adj-RIB-Out without also being added to the local BGP speaker's forwarding table is outside the scope of this document.
このドキュメントの範囲の外にまた、地元のBGPスピーカーの推進テーブルに加えられないで外のAdj-RIBに加えられるルートをもたらすどんなローカルの方針もあります。
When the updating of the Adj-RIBs-Out and the Routing Table is complete, the local BGP speaker runs the Update-Send process of 9.2.
外のAdj-RIBsとルート設定Tableのアップデートが完全であるときに、地元のBGPスピーカーは9.2のUpdate発信している過程を走らせます。
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. Because 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 shorter prefix); similarly, a route describing a larger set of destinations is said to be less specific than a route describing a smaller set of destinations.
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セットの目的地
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.
オーバラップによって説明された目的地のセットは可能な、しかし、現在使用中でないそれほど特定でないルートの一部を表します。 より特定のルートが後で引っ込められると、オーバラップによって説明された目的地のセットは、それほど特定でないルートを使用することでまだ届いているでしょう。
If a BGP speaker receives overlapping routes, the Decision Process MUST consider both routes based on the configured acceptance policy. If both a less and a more specific route are accepted, then the Decision Process MUST install, in Loc-RIB, either both the less and
BGPスピーカーがルートを重ね合わせながら受信するなら、Decision Processは構成された承認方針に基づく両方のルートを考えなければなりません。 両方であるなら、より少ないルートと、より特定のルートを受け入れます、次に、少しもよりそして、Decision ProcessはLoc-RIBにインストールしてはいけません。
Rekhter, et al. Standards Track [Page 83] RFC 4271 BGP-4 January 2006
Rekhter、他 標準化過程[83ページ]RFC4271BGP-2006年1月4日
the more specific routes or aggregate the two routes and install, in Loc-RIB, the aggregated route, provided that both routes have the same value of the NEXT_HOP attribute.
2が発送して、インストールする特定のルートか集合が、より多いです、Loc-RIB、集められたルートで、両方のルートにネクスト_HOP属性の同じ値があれば。
If a BGP speaker chooses to aggregate, then it SHOULD either include all ASes used to form the aggregate in an AS_SET, or add the ATOMIC_AGGREGATE attribute to the route. This attribute is now primarily informational. With the elimination of IP routing protocols that do not support classless routing, and the elimination of router and host implementations that do not support classless routing, there is no longer a need to de-aggregate. Routes SHOULD NOT be de-aggregated. In particular, a route that carries the ATOMIC_AGGREGATE attribute MUST NOT be de-aggregated. That is, the NLRI of this route cannot be more specific. Forwarding along such a route does not guarantee that IP packets will actually traverse only ASes listed in the AS_PATH attribute of the route.
BGPスピーカーは、集めるのを選んで、次に、それはSHOULDです。AS_SETの集合を形成するのに使用されるすべてのASesを含めるか、またはATOMIC_AGGREGATE属性をルートに追加してください。 この属性は現在、主として情報です。 階級のないルーティングを支持しないIPルーティング・プロトコルの除去、および階級のないルーティングを支持しないルータとホスト導入の除去と共に、反-集める必要がもうありません。 SHOULD NOTを発送する、反-集められます。 特に、反-ATOMIC_AGGREGATE属性を運ぶルートを集めてはいけません。 すなわち、このルートのNLRIは、より特定であるはずがありません。 そのようなルートに沿った推進は、IPパケットが実際にルートのAS_PATH属性で記載されたASesだけを横断するのを保証しません。
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.
すべての同輩にとって、Update発信している過程は広告UPDATEメッセージに原因となります。 例えば、それはDecision Processによって同じ自律システムか隣接している自律システムのどちらかに位置するかもしれない他のBGPスピーカーに選ばれたルートを分配します。
When a BGP speaker receives an UPDATE message from an internal peer, the receiving BGP speaker SHALL NOT re-distribute the routing information contained in that UPDATE message to other internal peers (unless the speaker acts as a BGP Route Reflector [RFC2796]).
BGPスピーカーが内部の同輩からUPDATEメッセージを受け取るとき、受信BGPスピーカーSHALL NOTはそのUPDATEメッセージに他の内部の同輩に含まれたルーティング情報を再配付します(スピーカーがBGP Route Reflector[RFC2796]として務めない場合)。
As part of Phase 3 of the route selection process, the BGP speaker has updated its Adj-RIBs-Out. All newly installed routes and all newly unfeasible routes for which there is no replacement route SHALL be advertised to its peers by means of an UPDATE message.
ルート選択の過程のPhase3の一部として、BGPスピーカーは外のAdj-RIBsをアップデートしました。 すべてが新たにルートと交換ルートがないSHALLがあるすべての新たに実行不可能なルートをインストールしました。UPDATEメッセージによって同輩に広告を出します。
A BGP speaker SHOULD NOT advertise a given feasible BGP route from its Adj-RIB-Out if it would produce an UPDATE message containing the same BGP route as was previously advertised.
BGPが以前に広告に掲載されていたように発送する同じくらいを含むUPDATEメッセージを出すなら、BGPスピーカーSHOULD NOTは外のAdj-RIBから与えられた可能な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でSHALLをマークしました。取り外されます。 広告を出しているコネがUPDATEメッセージであったならそれ自身の自律システムSHALLの中の届いている目的地にも変化します。
If, due to the limits on the maximum size of an UPDATE message (see Section 4), a single route doesn't fit into the message, the BGP speaker MUST not advertise the route to its peers and MAY choose to log an error locally.
ただ一つのルートがUPDATEメッセージ(セクション4を見る)の最大サイズにおける限界のためメッセージに収まらないなら、BGPスピーカーは、同輩にルートの広告を出してはいけなくて、局所的に誤りを登録するのを選ぶかもしれません。
Rekhter, et al. Standards Track [Page 84] RFC 4271 BGP-4 January 2006
Rekhter、他 標準化過程[84ページ]RFC4271BGP-2006年1月4日
9.2.1. Controlling Routing Traffic Overhead
9.2.1. ルート設定交通オーバーヘッドを制御します。
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メッセージに含んだUPDATEメッセージの広告を出すのに必要であるリンク帯域幅と読みこなすためにDecision Processによって必要とされた処理能力の両方を制限するために。
9.2.1.1. Frequency of Route Advertisement
9.2.1.1. ルート広告の頻度
The parameter MinRouteAdvertisementIntervalTimer determines the minimum amount of time that must elapse between an advertisement and/or withdrawal of routes to a particular destination by a BGP speaker to a peer. This rate limiting procedure applies on a per- destination basis, although the value of MinRouteAdvertisementIntervalTimer is set on a per BGP peer basis.
パラメタMinRouteAdvertisementIntervalTimerはルートの広告、そして/または、退出の間でBGPスピーカーで特定の目的地に経過しなければならない最小の時間を同輩に決定します。 手順を制限するこのレートがaで適用される、-、MinRouteAdvertisementIntervalTimerの値はBGP同輩基礎あたりのaに設定されますが、目的地基礎。
Two UPDATE messages sent by a BGP speaker to a peer that advertise feasible routes and/or withdrawal of unfeasible routes to some common set of destinations MUST be separated by at least MinRouteAdvertisementIntervalTimer. This can only be achieved by keeping a separate timer for each common set of destinations. This would be unwarranted overhead. Any technique that ensures that the interval between two UPDATE messages sent from a BGP speaker to a peer that advertise feasible routes and/or withdrawal of unfeasible routes to some common set of destinations will be at least MinRouteAdvertisementIntervalTimer, and will also ensure that a constant upper bound on the interval is acceptable.
少なくともMinRouteAdvertisementIntervalTimerはBGPスピーカーによって実行不可能なルートの可能なルート、そして/または、退出の何らかの一般的なセットの目的地に広告を出す同輩に送られた2つのUPDATEメッセージを切り離さなければなりません。 それぞれの一般的なセットの目的地に別々のタイマを保つことによって、これを達成できるだけです。 これは保証のないオーバーヘッドでしょう。 可能なルートの広告を出してください、何らかの一般的なセットの目的地への実行不可能なルートの退出が広告を出すというBGPスピーカーから同輩に送られた2つのUPDATEメッセージの間隔が少なくともMinRouteAdvertisementIntervalTimerであることを確実にして、また間隔の一定の上限が許容できるのを確実にするどんなテクニック。
Since fast convergence is needed within an autonomous system, either (a) the MinRouteAdvertisementIntervalTimer used for internal peers SHOULD be shorter than the MinRouteAdvertisementIntervalTimer used for external peers, or (b) the procedure describe in this section SHOULD NOT apply to routes sent to internal peers.
速い集合が必要であるので、自律システムの中では、(a) MinRouteAdvertisementIntervalTimerはSHOULD NOTが申し込む(b) 外部の同輩、または手順に、中古のMinRouteAdvertisementIntervalTimerがこれで説明するより短いセクションが内部の同輩に送られたルートであったなら内部の同輩にSHOULDを使用しました。
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 MinRouteAdvertisementIntervalTimer, the last route selected SHALL be advertised at the end of MinRouteAdvertisementIntervalTimer.
この手順はルート選択の速度を制限するのではなく、ルート広告の速度だけを制限します。 新しいルートが待っている間、複数の回選択されるなら、MinRouteAdvertisementIntervalTimerの満了、最後のルートはSHALLを選択しました。MinRouteAdvertisementIntervalTimerの端では、広告を出します。
9.2.1.2. Frequency of Route Origination
9.2.1.2. ルート創作の頻度
The parameter MinASOriginationIntervalTimer 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.
パラメタMinASOriginationIntervalTimerは広告BGPスピーカーの自己の自律システムの中で変化を報告するUPDATEメッセージの連続した広告の間で経過しなければならない最小の時間を決定します。
Rekhter, et al. Standards Track [Page 85] RFC 4271 BGP-4 January 2006
Rekhter、他 標準化過程[85ページ]RFC4271BGP-2006年1月4日
9.2.2. Efficient Organization of Routing Information
9.2.2. 経路情報の効率的な組織
Having selected the routing information it will advertise, a BGP speaker may avail itself of several methods to organize this information in an efficient manner.
それが広告を出すルーティング情報を選択したので、BGPスピーカーは効率的な方法でこの情報を組織化するいくつかの方法をそれ自体に利用するかもしれません。
9.2.2.1. Information Reduction
9.2.2.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 Section 9.2.2.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で.2に説明されたルート集合アルゴリズムで使用されます。 彼らは一度だけそれぞれのAS番号を記載することによって、AS_PATH情報のサイズを減少させます、何回複数のAS_PATHsでそれが集められたように見えたかもしれないかにかかわらず。
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 because such
paths are no longer listed individually in the form of
AS_SEQUENCEs. In practice, this is not likely to be a problem
because once an IP packet arrives at the edge of a group of
autonomous systems, the BGP speaker is likely to have more
detailed path information and can distinguish individual paths
from destinations.
AS_SETは、NLRIに記載された目的地に少なくともいくつかの構成している自律システムを横断する経路を通して達することができるのを含意します。AS_SETsは情報ループを発送するのを避けるために十分な情報を前提とします。 しかしながら、そのような経路がもうAS_SEQUENCEsの形に個別に記載されていないので、彼らの使用は潜在的に可能な経路を剪定するかもしれません。 実際には、IPパケットがいったん自律システムのグループの縁に到着すると、BGPスピーカーが、より詳細な経路情報を持ちそうであって、目的地と個々の経路を区別できるので、これは問題である傾向がありません。
Rekhter, et al. Standards Track [Page 86] RFC 4271 BGP-4 January 2006
Rekhter、他 標準化過程[86ページ]RFC4271BGP-2006年1月4日
9.2.2.2. Aggregating Routing Information
9.2.2.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に置かれるルーティング情報の量を減少させるためにDecision Processの一部として起こることができます。
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 the same type and to the Network Layer Reachability Information.
集合は他のBGPスピーカーと共にBGPスピーカーが格納しなければならない情報と交換の量を減少させます。 別々に同じタイプの経路属性と、そして、Network Layer Reachability情報に以下の手順を適用することによって、ルートを集めることができます。
Routes that have different MULTI_EXIT_DISC attributes SHALL NOT be aggregated.
異なった_DISC属性MULTI_EXIT SHALL NOTを集めるルート。
If the aggregated route has an AS_SET as the first element in its AS_PATH attribute, then the router that originates the route SHOULD NOT advertise the MULTI_EXIT_DISC attribute with this route.
集められたルートにAS_PATH属性における最初の要素としてAS_SETがあるなら、ルートSHOULD NOTを溯源するルータはこのルートでMULTI_EXIT_DISC属性の広告を出します。
Path attributes that have different type codes cannot be aggregated together. Path attributes of the same type code may be aggregated, according to the following rules:
異なったタイプコードを持っている経路属性は一緒に集めることができません。 以下の規則に従って、同じタイプコードの経路属性は集められるかもしれません:
NEXT_HOP:
When aggregating routes that have different NEXT_HOP
attributes, the NEXT_HOP attribute of the aggregated route
SHALL identify an interface on the BGP speaker that performs
the aggregation.
次の_ホップ: 異なったネクスト_HOP属性を持っているルートに集めるとき、集められたルートSHALLのネクスト_HOP属性は集合を実行するBGPスピーカーの上でインタフェースを特定します。
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 cases,, the value of the ORIGIN attribute of the
aggregated route is IGP.
ORIGINは以下を結果と考えます。 集められるルートの中の少なくとも1つのルートに値のINCOMPLETEとORIGINがあるなら、集められたルートには、値のINCOMPLETEがあるORIGIN属性がなければなりません。 さもなければ、集められるルートの中の少なくとも1つのルートに値のEGPとORIGINがあるなら、集められたルートには値のEGPがあるORIGIN属性がなければなりません。 他のすべての場合で集められたルートのORIGIN属性の値はIGPです。
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
AS_PATH属性に集める目的のために、私たちはtuple<タイプとしてAS_PATH属性の中で各ASをモデル化します、値の>、「タイプ」が経路セグメントのタイプのためにASを特定するところで
Rekhter, et al. Standards Track [Page 87] RFC 4271 BGP-4 January 2006
Rekhter、他 標準化過程[87ページ]RFC4271BGP-2006年1月4日
belongs to (e.g., AS_SEQUENCE, AS_SET), and "value" identifies
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属性SHALLは以下の条件のすべてを満たします:
- all tuples of type AS_SEQUENCE in the aggregated AS_PATH
SHALL appear in all of the AS_PATHs in the initial set of
routes to be aggregated.
- 集められたAS_PATH SHALLのタイプAS_SEQUENCEのすべてのtuplesがAS_PATHsのすべてに集められるべきルートの始発に現れます。
- all tuples of type AS_SET in the aggregated AS_PATH SHALL
appear in at least one of the AS_PATHs in the initial set
(they may appear as either AS_SET or AS_SEQUENCE types).
- 集められたAS_PATH SHALLのタイプAS_SETのすべてのtuplesが少なくともAS_PATHsの1つに始発に現れます(AS_SETかAS_SEQUENCEのどちらかがタイプするように彼らは見えるかもしれません)。
- for any tuple X of 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のタイプAS_SEQUENCEのどんなtuple Xに関してはも、Xは始発における各AS_PATHでYに先行します、Yのタイプにかかわらず。PATHは集められたAS_PATHでtuple Yに先行します。始発はYを含みます。
- No tuple of type AS_SET with the same value SHALL appear
more than once in the aggregated AS_PATH.
- 同じ値のSHALLとタイプAS_SETのtupleは全く集められたAS_PATHで一度より多く見えません。
- Multiple tuples of type AS_SEQUENCE with the same value may
appear in the aggregated AS_PATH only when adjacent to
another tuple of the same type and value.
- 同じタイプと価値の別のtupleに隣接して現れるときだけ、同じ値があるタイプAS_SEQUENCEの複数のtuplesが集められたAS_PATHに現れるかもしれません。
An implementation may choose any algorithm that 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:
実現はこれらの規則に従うどんなアルゴリズムも選ぶかもしれません。 aでは、最小限、aは実現SHALLを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つ以外のすべてを排除してください。
- for each pair of adjacent tuples in the aggregated AS_PATH,
if both tuples have the same type, merge them together, as
long as doing so will not cause a segment with a length
greater than 255 to be generated.
- 集められたAS_PATHの各組の隣接しているtuplesに関しては、両方のtuplesに同じタイプがあるなら、彼らを結合させてください、そうするのが255以上の長さがあるセグメントを発生させない限り。
Rekhter, et al. Standards Track [Page 88] RFC 4271 BGP-4 January 2006
Rekhter、他 標準化過程[88ページ]RFC4271BGP-2006年1月4日
Appendix F, Section F.6 presents another algorithm that
satisfies the conditions and allows for more complex policy
configurations.
付録F、セクションF.6は条件を満たして、より複雑な方針構成を考慮する別のアルゴリズムを提示します。
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経路属性があるなら、集められたルートSHALLには、また、この属性があります。
AGGREGATOR:
Any AGGREGATOR attributes from the routes to be aggregated MUST
NOT be included in the aggregated route. The BGP speaker
performing the route aggregation MAY attach a new AGGREGATOR
attribute (see Section 5.1.7).
アグリゲータ: 集められたルートに集められるべきルートからのどんなAGGREGATOR属性も含んではいけません。 ルート集合を実行しているBGPスピーカーは新しいAGGREGATOR属性を付けるかもしれません(セクション5.1.7を見てください)。
9.3. Route Selection Criteria
9.3. ルート選択評価基準
Generally, 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 (provided that the speaker is configured to
accept such routes). If such a route were ever used, a routing
loop could result.
- 考えられて、地方のASが新しいルートのAS経路に現れるなら、いかなる他のルートよりも良いとしてその新しいルートを見なすことができません(スピーカーがそのようなルートを受け入れるために構成されれば)。 そのようなルートが今までに使用されたなら、ルーティング輪は結果として生じるかもしれません。
- In order to achieve a successful distributed operation, only
routes with a likelihood of stability can be chosen. Thus, an
AS SHOULD avoid using unstable routes, and it SHOULD NOT make
rapid, spontaneous changes to its choice of route. Quantifying
the terms "unstable" and "rapid" (from the previous sentence)
will require experience, but the principle is clear. Routes
that are unstable can be "penalized" (e.g., by using the
procedures described in [RFC2439]).
- うまくいっている分配された操作を達成するために、安定性の見込みがあるルートしか選ぶことができません。 したがって、AS SHOULDは、不安定なルート、およびそれを使用するのをSHOULD NOT造の急速な状態で避けます、ルートの選択への自発変化。 「不安定で」「急速な」状態で(前の文からの)用語を定量化するのは経験を必要とするでしょうが、原則は明確です。 不安定なルートは「罰することができる」(例えば、[RFC2439]で説明された手順を用いることによって)。
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 assigns the degree of preference (e.g., according to local configuration) 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 update process (see Section 9.2). The decision of whether to distribute non-BGP acquired routes within an AS via BGP 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を見てください)。 また、これらのルートは更新処理の一部として地方のASの中の他のBGPスピーカーに分配されるかもしれません(セクション9.2を見てください)。 制御されていて、BGPを通してASの中で非BGPの後天的なルートを分配するかどうかに関する決定は構成でAS(例えば、IGPのタイプ)とSHOULDの中の環境に依存します。
Rekhter, et al. Standards Track [Page 89] RFC 4271 BGP-4 January 2006
Rekhter、他 標準化過程[89ページ]RFC4271BGP-2006年1月4日
10. BGP Timers
10. BGPタイマ
BGP employs five timers: ConnectRetryTimer (see Section 8), HoldTimer (see Section 4.2), KeepaliveTimer (see Section 8), MinASOriginationIntervalTimer (see Section 9.2.1.2), and MinRouteAdvertisementIntervalTimer (see Section 9.2.1.1).
BGPは5個のタイマを使います: セクション9.2を見てください。ConnectRetryTimer(セクション8を見る)、HoldTimer(セクション4.2を見る)、KeepaliveTimer(セクション8を見る)、MinASOriginationIntervalTimer、(セクション9.2.1の.2、)およびMinRouteAdvertisementIntervalTimerを見てください、(.1 .1)。
Two optional timers MAY be supported: DelayOpenTimer, IdleHoldTimer by BGP (see Section 8). Section 8 describes their use. The full operation of these optional timers is outside the scope of this document.
2個の任意のタイマが支えられるかもしれません: DelayOpenTimer、BGP(セクション8を見る)によるIdleHoldTimer。 セクション8は彼らの使用について説明します。 このドキュメントの範囲の外にこれらの任意のタイマの稼業があります。
ConnectRetryTime is a mandatory FSM attribute that stores the initial value for the ConnectRetryTimer. The suggested default value for the ConnectRetryTime is 120 seconds.
ConnectRetryTimeはConnectRetryTimerのために初期の値を格納する義務的なFSM属性です。 ConnectRetryTimeのための提案されたデフォルト値は120秒です。
HoldTime is a mandatory FSM attribute that stores the initial value for the HoldTimer. The suggested default value for the HoldTime is 90 seconds.
HoldTimeはHoldTimerのために初期の値を格納する義務的なFSM属性です。 HoldTimeのための提案されたデフォルト値は90秒です。
During some portions of the state machine (see Section 8), the HoldTimer is set to a large value. The suggested default for this large value is 4 minutes.
州のマシン(セクション8を見る)のいくつかの一部、HoldTimerは大きい値に用意ができています。 この大きい値のための提案されたデフォルトは4分です。
The KeepaliveTime is a mandatory FSM attribute that stores the initial value for the KeepaliveTimer. The suggested default value for the KeepaliveTime is 1/3 of the HoldTime.
KeepaliveTimeはKeepaliveTimerのために初期の値を格納する義務的なFSM属性です。 KeepaliveTimeのための提案されたデフォルト値は1/3HoldTimeです。
The suggested default value for the MinASOriginationIntervalTimer is 15 seconds.
MinASOriginationIntervalTimerのための提案されたデフォルト値は15秒です。
The suggested default value for the MinRouteAdvertisementIntervalTimer on EBGP connections is 30 seconds.
EBGP接続でのMinRouteAdvertisementIntervalTimerのための提案されたデフォルト値は30秒です。
The suggested default value for the MinRouteAdvertisementIntervalTimer on IBGP connections is 5 seconds.
IBGP接続でのMinRouteAdvertisementIntervalTimerのための提案されたデフォルト値は5秒です。
An implementation of BGP MUST allow the HoldTimer to be configurable on a per-peer basis, and MAY allow the other timers to be configurable.
BGP MUSTの実装は、HoldTimerが1同輩あたり1個のベースで構成可能であることを許容して、他のタイマが構成可能であることを許容するかもしれません。
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 MinASOriginationIntervalTimer, KeepaliveTimer, MinRouteAdvertisementIntervalTimer, and ConnectRetryTimer. A given BGP speaker MAY apply the same jitter to each of these quantities, regardless of the destinations to which the updates are being sent; that is, jitter need not be configured on a per-peer basis.
与えられたBGPスピーカーによるBGPメッセージの分配がピーク、ジターSHOULDを含むという見込みを最小にするには、MinASOriginationIntervalTimer、KeepaliveTimer、MinRouteAdvertisementIntervalTimer、およびConnectRetryTimerに関連しているタイマに適用されてください。 与えられたBGPスピーカーはそれぞれのこれらの量に同じジターを適用するかもしれません、アップデートが送られる目的地にかかわらず。 すなわち、ジターは1同輩あたり1個のベースで構成される必要はありません。
Rekhter, et al. Standards Track [Page 90] RFC 4271 BGP-4 January 2006
Rekhter、他 標準化過程[90ページ]RFC4271BGP-2006年1月4日
The suggested default amount of jitter 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. A new random value SHOULD be picked each time the timer is set. The range of the jitter's random value MAY be configurable.
提案されたデフォルトはジターSHALLを達させます。適切なタイマの基礎点を偶然要因に掛けることによって、断固としてください。(偶然要因は0.75〜1.0までの範囲で一様に分配されます)。 SHOULDを評価してください。新しく無作為である、タイマが設定されるたびに選ばれてください。 ジターの無作為の価値の範囲は構成可能であるかもしれません。
Rekhter, et al. Standards Track [Page 91] RFC 4271 BGP-4 January 2006
Rekhter、他 標準化過程[91ページ]RFC4271BGP-2006年1月4日
Appendix A. Comparison with RFC 1771
RFC1771との付録A.比較
There are numerous editorial changes in comparison to [RFC1771] (too many to list here).
[RFC1771](ここに記載できないくらいの多くの)との比較における多数の編集の変化があります。
The following list the technical changes:
以下は技術変化を記載します:
Changes to reflect the usage of features such as TCP MD5
[RFC2385], BGP Route Reflectors [RFC2796], BGP Confederations
[RFC3065], and BGP Route Refresh [RFC2918].
用法を反映する変化はTCP MD5などのように[RFC2385]、BGP Route Reflectors[RFC2796]、BGP Confederations[RFC3065]、およびBGP Route Refresh[RFC2918]を特集します。
Clarification of the use of the BGP Identifier in the AGGREGATOR
attribute.
AGGREGATOR属性におけるBGP Identifierの使用の明確化。
Procedures for imposing an upper bound on the number of prefixes
that a BGP speaker would accept from a peer.
BGPスピーカーが同輩から受け入れる接頭語の数に上限を課すための手順。
The ability of a BGP speaker to include more than one instance of
its own AS in the AS_PATH attribute for the purpose of inter-AS
traffic engineering.
BGPスピーカーが相互AS交通工学の目的のためのAS_PATH属性にそれ自身のASの1つ以上のインスタンスを含む能力。
Clarification of the various types of NEXT_HOPs.
ネクスト_HOPsの様々なタイプの明確化。
Clarification of the use of the ATOMIC_AGGREGATE attribute.
ATOMIC_AGGREGATE属性の使用の明確化。
The relationship between the immediate next hop, and the next hop
as specified in the NEXT_HOP path attribute.
次の即座のホップと、ネクスト_HOP経路属性における指定されるとしての次のホップとの関係。
Clarification of the tie-breaking procedures.
繋がりを壊す手順の明確化。
Clarification of the frequency of route advertisements.
ルート広告の頻度の明確化。
Optional Parameter Type 1 (Authentication Information) has been
deprecated.
任意のParameter Type1(認証情報)は推奨しないです。
UPDATE Message Error subcode 7 (AS Routing Loop) has been
deprecated.
UPDATE Message Error部分符号7(ASルート設定Loop)は推奨しないです。
OPEN Message Error subcode 5 (Authentication Failure) has been
deprecated.
オープンMessage Error部分符号5(認証Failure)は推奨しないです。
Use of the Marker field for authentication has been deprecated.
Marker分野の認証の使用は推奨しないです。
Implementations MUST support TCP MD5 [RFC2385] for authentication.
実装は認証のために、TCP MD5[RFC2385]をサポートしなければなりません。
Clarification of BGP FSM.
BGP FSMの明確化。
Rekhter, et al. Standards Track [Page 92] RFC 4271 BGP-4 January 2006
Rekhter、他 標準化過程[92ページ]RFC4271BGP-2006年1月4日
Appendix B. Comparison with RFC 1267
RFC1267との付録B.比較
All the changes listed in Appendix A, plus the following.
すべての変化がAppendix A、および以下に記載しました。
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 the 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 [RFC1518, RFC1519].
BGP-4は1セットの届いている目的地がただ一つのIP接頭語で言い表されるかもしれないところで環境で作動できます。 ネットワークのクラス、またはサブネッティングの概念はBGP-4に外国です。 これらの能力を収容するために、BGP-4はAS_PATH属性に関連している意味論とコード化を変えます。 新しいテキストは、IP接頭語に関連している意味論を定義するために加えられます。 これらの能力で、BGP-4は、提案されたスーパーネッティング体系が[RFC1518、RFC1519]であるとサポートすることができます。
To simplify configuration, this version introduces a new attribute, LOCAL_PREF, that facilitates route selection procedures.
構成を簡素化するために、このバージョンは新しい属性、ルート選択手順を容易にするLOCAL_PREFを導入します。
The INTER_AS_METRIC attribute has been renamed MULTI_EXIT_DISC.
INTER_AS_METRIC属性は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 to advertise which AS and which BGP speaker within that AS caused the aggregation.
ある集合が反-集められないのを保障するために、新しい属性(ATOMIC_AGGREGATE)を導入しました。 集合が引き起こされたそのASの中にどのASとどのBGPスピーカーの広告を出すかためにルートに集めるために、別の新しい属性(AGGREGATOR)を加えることができます。
To ensure that Hold Timers are symmetric, the Hold Timer is now negotiated on a per-connection basis. Hold Timers of zero are now supported.
Hold Timersが確実に左右対称になるようにするために、Hold Timerは現在、1接続あたり1個のベースに関して交渉されます。 ゼロの保持Timersは現在、サポートされます。
Appendix C. Comparison with RFC 1163
RFC1163との付録C.比較
All of the changes listed in Appendices A and B, plus the following.
変化のすべてがAppendices A、B、および以下に記載しました。
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 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経路属性で通過されるルータを制限しません。
The new document optimizes and simplifies the exchange of information about previously reachable routes.
新しいドキュメントは、以前に届いているルートに関して情報交換を最適化して、簡素化します。
Rekhter, et al. Standards Track [Page 93] RFC 4271 BGP-4 January 2006
Rekhter、他 標準化過程[93ページ]RFC4271BGP-2006年1月4日
Appendix D. Comparison with RFC 1105
RFC1105との付録D.比較
All of the changes listed in Appendices A, B, and C, plus the following.
変化のすべてがAppendices A、B、C、および以下に記載しました。
Minor changes to the [RFC1105] Finite State Machine were necessary to accommodate the TCP user interface provided by BSD version 4.3.
[RFC1105]有限州Machineへのマイナーチェンジが、BSDバージョン4.3によって提供されたTCPユーザーインタフェースを収容するのに必要でした。
The notion of Up/Down/Horizontal relations presented in RFC 1105 has been removed from the protocol.
プロトコルからRFC1105に提示された下がっているかUp/水平な関係の概念を取り除きました。
The changes in the message format from RFC 1105 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メッセージによって提供された暗黙の確認に、排除して、取り替えました。
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 [RFC1163], is referred to as BGP-2; BGP, as specified in RFC 1267 is referred to as BGP-3; and BGP, as specified in this document is referred to as BGP-4.
かなりしばしばRFC1105で指定されるBGPがBGP-1と呼ばれることに注意してください。 [RFC1163]で指定されるBGPはBGP-2と呼ばれます。 BGP、指定されるように、RFC1267はBGP-3と呼ばれます。 BGP、そして、これで指定されるように、ドキュメントはBGP-4と呼ばれます。
Appendix E. TCP Options that May Be Used with BGP
付録E.TCP OptionsはBGPとその5月のBe Usedです。
If a local system TCP user interface supports the TCP PUSH function, then each BGP message SHOULD be transmitted with PUSH flag set. Setting PUSH flag forces BGP messages to be transmitted to the receiver promptly.
TCPユーザーインタフェースがTCP PUSH機能、次に、それぞれのBGPメッセージSHOULDをサポートするローカルシステムがPUSHが伝えられる状態で弛むということであるなら、セットしてください。 PUSHが旗を揚げさせる設定は即座に受信機に伝えられるべきBGPメッセージを強制します。
If a local system TCP user interface supports setting the DSCP field [RFC2474] for TCP connections, then the TCP connection used by BGP SHOULD be opened with bits 0-2 of the DSCP field set to 110 (binary).
ローカルシステムTCPユーザーインタフェースが、設定がDSCP分野[RFC2474]であるとサポートするなら、TCP接続、次に接続がBGP SHOULDで使用したTCPに関して、DSCP分野セットのビット0-2で110(2進の)まで開かれてください。
An implementation MUST support the TCP MD5 option [RFC2385].
実装は、TCP MD5がオプション[RFC2385]であるとサポートしなければなりません。
Rekhter, et al. Standards Track [Page 94] RFC 4271 BGP-4 January 2006
Rekhter、他 標準化過程[94ページ]RFC4271BGP-2006年1月4日
Appendix F. Implementation Recommendations
付録F.実装推薦
This section presents some implementation recommendations.
このセクションはいくつかの実装推薦を提示します。
Appendix F.1. Multiple Networks Per Message
付録F.1。 複数の1メッセージあたりのネットワーク
The BGP protocol allows for multiple address prefixes with the same path attributes to be specified in one message. Using 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.
BGPプロトコルは、同じ経路属性がある複数のアドレス接頭語が1つのメッセージで指定されるのを許容します。 この能力を使用するのは非常にお勧めです。 1メッセージあたり1つのアドレス接頭語と共に、オーバーヘッドのかなりの増加が受信機にあります。また、システムオーバーヘッドが複数のメッセージのレセプションのため上がるだけではなく、BGP同輩へのアップデートと他のルーティング・プロトコル(関連メッセージを送って)のために経路指定テーブルをスキャンするオーバーヘッドは複数の回被られます。
One method of building messages that contain many address prefixes per path attribute set from a routing table that is not organized on a per path attribute set basis is to build many messages as the routing table is scanned. As each address prefix is processed, a message for the associated set of path attributes 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 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 allocated messages are sent and their resources are released. Maximum compression is achieved when all destinations covered by the address prefixes share a common set of path attributes, making it possible to send many address prefixes in one 4096-byte message.
経路属性セット基礎あたりのaで組織化されない経路指定テーブルから多くの経路属性セットあたりのアドレス接頭語を含むメッセージを築き上げるあるメソッドは経路指定テーブルがスキャンされるとき多くのメッセージを築き上げることです。 それぞれのアドレス接頭語を処理するとき、関連セットの経路属性へのメッセージを割り当てます、存在していなくて、新しいアドレス接頭語がそれに加えられるなら。 そのようなメッセージが存在しているなら、新しいアドレス接頭語をそれに追加します。 メッセージが新しいアドレス接頭語を保持するスペースを欠いているなら、それを伝えます、そして、新しいメッセージを割り当てます、そして、新しいアドレス接頭語を新しいメッセージに挿入します。 全体の経路指定テーブルをスキャンしたとき、すべての割り当てられたメッセージを送ります、そして、それらのリソースを発表します。 アドレス接頭語でカバーされたすべての目的地が一般的なセットの経路属性を共有するとき、最大の圧縮は達成されます、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 when 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同輩のためのフラッシュ最新版と他のルーティング・プロトコルを提供するために経路指定テーブルの余分なスキャンを排除するでしょう。 このアプローチの不都合はルーティング情報の伝播潜在を増強するということです。 わざわざそれが複数のメッセージを処理するあまり長くない最小のフラッシュアップデート間隔を選ぶことによって、この潜在は最小にされるべきです。 より良いメソッドはアップデートを送る前にすべての受信されたメッセージを読むだろうことです。
Rekhter, et al. Standards Track [Page 95] RFC 4271 BGP-4 January 2006
Rekhter、他 標準化過程[95ページ]RFC4271BGP-2006年1月4日
Appendix F.2. Reducing Route Flapping
付録F.2。 ルートのばたつくことを減少させます。
To avoid excessive route flapping, a BGP speaker that needs to withdraw a destination and send an update about a more specific or less specific route should combine them into the same UPDATE message.
過度のルートのばたつくことを避けるために、より特定の、または、それほど特定でないルートに関して目的地を引き下がらせて、アップデートを送る必要があるBGPスピーカーは、同じUPDATEメッセージにそれらを結合するべきです。
Appendix F.3. Path Attribute Ordering
付録F.3。 経路属性注文
Implementations that combine update messages (as described above in Section 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 that 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で上で説明されるように)を結合する実装は、すべての経路属性が知られているオーダーに示されるのを見るのを好むかもしれません。 これは、彼らが意味的に同じ異なったアップデートメッセージから属性のセットをすぐに特定することを許可します。 これを容易にするために、タイプコードによると、経路属性を命令するのは、役に立つ最適化です。 この最適化は完全に任意です。
Appendix F.4. AS_SET Sorting
付録F.4。 _セットソーティングとして
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番号を分類することです。 この最適化は完全に任意です。
Appendix F.5. Control Over Version Negotiation
付録F.5。 バージョン交渉のコントロール
Because BGP-4 is capable of carrying aggregated routes that cannot be properly represented in BGP-3, an implementation that 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を話すだけである能力を提供するべきです。
Appendix F.6. Complex AS_PATH Aggregation
付録F.6。 _経路集合として、複雑です。
An implementation that chooses to provide a path aggregation algorithm retaining 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 ASes 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番号です。 2ASesが彼らの対応する<タイプであるなら同じであると言われて、値の>tuplesは同じです。
The algorithm to aggregate two AS_PATH attributes works as
follows:
2つのAS_PATH属性に集めるアルゴリズムは以下の通り利きます:
a) Identify the same ASes (as defined above) within each
AS_PATH attribute that are in the same relative order within
both AS_PATH attributes. Two ASes, X and Y, are said to be
in the same order if either:
a) それぞれのAS_PATH属性の中の両方のAS_PATH属性の中に同じ相対オーダにはあるのと同じASes(上で定義されるように)を特定してください。 2ASes(XとY)がどちらかなら同次にはあると言われます:
Rekhter, et al. Standards Track [Page 96] RFC 4271 BGP-4 January 2006
Rekhter、他 標準化過程[96ページ]RFC4271BGP-2006年1月4日
- 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 ASes identified
in (a), in exactly the same order as they appear in the
AS_PATH attributes to be aggregated. If two consecutive
ASes identified in (a) do not immediately follow each other
in both of the AS_PATH attributes to be aggregated, then the
intervening ASes (ASes that are between the two consecutive
ASes that are the same) in both attributes are combined into
an AS_SET path segment that consists of the intervening ASes
from both AS_PATH attributes. This segment is then placed
between the two consecutive ASes identified in (a) of the
aggregated attribute. If two consecutive ASes identified in
(a) immediately follow each other in one attribute, but do
not follow in another, then the intervening ASes of the
latter are combined into an AS_SET path segment. This
segment is then placed between the two consecutive ASes
identified in (a) of the aggregated attribute.
b) 彼らは、集められるべきAS_PATH属性で(a)、まさに同じオーダーで特定されているように見えますが、集められたAS_PATH属性はASesから成ります。 (a)で特定された2連続したASesがすぐに集められるためにAS_PATH属性の両方で互いに続かないなら、両方の属性における介入しているASes(2同じである連続したASesの間にあるASes)は両方のAS_PATH属性からの介入しているASesから成るAS_SET経路セグメントに結合されます。 そして、このセグメントは集められた属性の(a)で特定された2連続したASesの間に置かれます。 すぐに(a)で特定された2連続したASesが1つの属性で互いに続きますが、別のもので続かないなら、後者の介入しているASesはAS_SET経路セグメントに結合されます。 そして、このセグメントは集められた属性の(a)で特定された2連続したASesの間に置かれます。
c) For each pair of adjacent tuples in the aggregated AS_PATH,
if both tuples have the same type, merge them together if
doing so will not cause a segment of a length greater than
255 to be generated.
c) 集められたAS_PATHの各組の隣接しているtuplesに関しては、両方のtuplesで同じタイプがあって、そうするのが255以上の長さのセグメントを生成させないなら、彼らを結合させてください。
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番号の最終審(一番右の発生)以外のすべてを取り除くべきです。
Security Considerations
セキュリティ問題
A BGP implementation MUST support the authentication mechanism specified in RFC 2385 [RFC2385]. The authentication provided by this mechanism could be done on a per-peer basis.
BGP実装はRFC2385[RFC2385]で指定された認証機構をサポートしなければなりません。 1同輩あたり1個のベースでこのメカニズムによって提供された認証ができました。
BGP makes use of TCP for reliable transport of its traffic between peer routers. To provide connection-oriented integrity and data origin authentication on a point-to-point basis, BGP specifies use of the mechanism defined in RFC 2385. These services are intended to detect and reject active wiretapping attacks against the inter-router TCP connections. Absent the use of mechanisms that effect these security services, attackers can disrupt these TCP connections and/or masquerade as a legitimate peer router. Because the mechanism defined in the RFC does not provide peer-entity authentication, these connections may be subject to some forms of replay attacks that will not be detected at the TCP layer. Such attacks might result in delivery (from TCP) of "broken" or "spoofed" BGP messages.
BGPは同輩ルータの間のトラフィックの信頼できる輸送にTCPを利用します。 二地点間ベースで接続指向の保全とデータ発生源認証を提供するために、BGPはRFC2385で定義されたメカニズムの使用を指定します。 これらのサービスは、相互ルータTCP接続に対して活発な盗聴攻撃を検出して、拒絶することを意図します。 これらのセキュリティー・サービスに作用するメカニズムの使用がなければ、攻撃者は、これらのTCP接続を中断する、そして/または、正統の同輩ルータのふりをすることができます。 RFCで定義されたメカニズムが同輩実体認証を提供しないので、これらの接続はTCP層に検出されないいくつかのフォームの反射攻撃を受けることがあるかもしれません。 そのような攻撃は「壊れている」か「偽造している」BGPメッセージの配送(TCPからの)をもたらすかもしれません。
Rekhter, et al. Standards Track [Page 97] RFC 4271 BGP-4 January 2006
Rekhter、他 標準化過程[97ページ]RFC4271BGP-2006年1月4日
The mechanism defined in RFC 2385 augments the normal TCP checksum with a 16-byte message authentication code (MAC) that is computed over the same data as the TCP checksum. This MAC is based on a one- way hash function (MD5) and use of a secret key. The key is shared between peer routers and is used to generate MAC values that are not readily computed by an attacker who does not have access to the key. A compliant implementation must support this mechanism, and must allow a network administrator to activate it on a per-peer basis.
TCPチェックサムと同じデータに関して計算される16バイトのメッセージ確認コード(MAC)によると、RFC2385で定義されたメカニズムは正常なTCPチェックサムを増大させます。 このMACは1つの方法に基づいて秘密鍵の機能(MD5)と使用を論じ尽くすことです。 キーは、同輩ルータの間で共有されて、キーに近づく手段を持っていない攻撃者によって容易に計算されない値をMACに生成するのに使用されます。 対応する実装は、このメカニズムをサポートしなければならなくて、ネットワーク管理者が1同輩あたり1個のベースでそれを動かすのを許容しなければなりません。
RFC 2385 does not specify a means of managing (e.g., generating, distributing, and replacing) the keys used to compute the MAC. RFC 3562 [RFC3562] (an informational document) provides some guidance in this area, and provides rationale to support this guidance. It notes that a distinct key should be used for communication with each protected peer. If the same key is used for multiple peers, the offered security services may be degraded, e.g., due to an increased risk of compromise at one router that adversely affects other routers.
RFC2385はMACを計算するキーが使用した(例えば、生成、分配、および取り替え)を管理する手段を指定しません。 RFC3562[RFC3562](情報のドキュメント)は、何らかの指導をこの領域に提供して、この指導をサポートするために原理を提供します。 それは、異なったキーがそれぞれの保護された同輩とのコミュニケーションに使用されるべきであることに注意します。 同じキーが複数の同輩に使用されるなら、提供されたセキュリティー・サービスは下がるかもしれません、例えば、他のルータに悪影響を与える1つのルータにおける感染の増強されたリスクのため。
The keys used for MAC computation should be changed periodically, to minimize the impact of a key compromise or successful cryptanalytic attack. RFC 3562 suggests a crypto period (the interval during which a key is employed) of, at most, 90 days. More frequent key changes reduce the likelihood that replay attacks (as described above) will be feasible. However, absent a standard mechanism for effecting such changes in a coordinated fashion between peers, one cannot assume that BGP-4 implementations complying with this RFC will support frequent key changes.
主要な感染かうまくいっているcryptanalytic攻撃の影響を最小にするために定期的にMAC計算に使用されるキーを変えるべきです。 RFC3562は大部分の90日間の暗号の期間(キーが採用している間隔)を勧めます。 より頻繁なキーチェンジは反射攻撃(上で説明されるように)が可能になるという見込みを減少させます。 しかしながら、同輩の間の連携ファッションにおけるそのような変化に作用するための標準のメカニズムがなければ、人は、このRFCに従うBGP-4実装が頻繁なキーチェンジをサポートすると仮定できません。
Obviously, each should key also be chosen to be difficult for an attacker to guess. The techniques specified in RFC 1750 for random number generation provide a guide for generation of values that could be used as keys. RFC 2385 calls for implementations to support keys "composed of a string of printable ASCII of 80 bytes or less." RFC 3562 suggests keys used in this context be 12 to 24 bytes of random (pseudo-random) bits. This is fairly consistent with suggestions for analogous MAC algorithms, which typically employ keys in the range of 16 to 20 bytes. To provide enough random bits at the low end of this range, RFC 3562 also observes that a typical ACSII text string would have to be close to the upper bound for the key length specified in RFC 2385.
明らかに、それぞれを合わせるべきです、また、攻撃者が推測するのが、難しいには、選ばれてください。 RFC1750で乱数発生に指定されたテクニックはキーとして使用できた値の世代のためのガイドを提供します。 RFC2385は、実装が「80バイト以下の印刷可能なASCIIのストリングで構成された」キーを支えるように求めます。 RFC3562は12〜24がバイトの無作為の(擬似ランダム)ビットであったならこのような関係においては使用されるキーを勧めます。 これは類似のMACアルゴリズムのための提案とかなり一致しています。(提案は16〜20バイトの範囲でキーを通常使います)。 また、この範囲のローエンドで十分な無作為のビット提供するために、RFC3562は、RFC2385で指定されたキー長のための上限の近くに典型的なACSIIテキスト文字列がなければならないのを観測します。
BGP vulnerabilities analysis is discussed in [RFC4272].
[RFC4272]でBGP脆弱性分析について議論します。
Rekhter, et al. Standards Track [Page 98] RFC 4271 BGP-4 January 2006
Rekhter、他 標準化過程[98ページ]RFC4271BGP-2006年1月4日
IANA Considerations
IANA問題
All the BGP messages contain an 8-bit message type, for which IANA has created and is maintaining a registry entitled "BGP Message Types". This document defines the following message types:
すべてのBGPメッセージがタイプ(IANAはそうした)が、作成されて、登録が「BGPメッセージタイプ」の権利を与えたと主張している8ビットのメッセージを含んでいます。 このドキュメントは以下のメッセージタイプを定義します:
Name Value Definition
---- ----- ----------
OPEN 1 See Section 4.2
UPDATE 2 See Section 4.3
NOTIFICATION 3 See Section 4.5
KEEPALIVE 4 See Section 4.4
名前値の定義---- ----- ---------- 開いている1は、セクション4.2 アップデート2が、セクション4.3 通知3が、セクション4.5 KEEPALIVE4がセクション4.4を見るのを見るのを見るのを見ます。
Future assignments are to be made using either the Standards Action process defined in [RFC2434], or the Early IANA Allocation process defined in [RFC4020]. Assignments consist of a name and the value.
将来の課題は[RFC2434]で定義されたStandards Actionプロセスか[RFC4020]で定義されたEarly IANA Allocationプロセスのどちらかを使用することで作られていることです。 課題は名前と価値から成ります。
The BGP UPDATE messages may carry one or more Path Attributes, where each Attribute contains an 8-bit Attribute Type Code. IANA is already maintaining such a registry, entitled "BGP Path Attributes". This document defines the following Path Attributes Type Codes:
BGP UPDATEメッセージは1Path Attributesを運ぶかもしれません。そこでは、各Attributeが8ビットのAttribute Type Codeを含みます。 IANAは既に「BGP経路属性」の権利を与えられたそのような登録を維持しています。 このドキュメントは以下のPath Attributes Type Codesを定義します:
Name Value Definition
---- ----- ----------
ORIGIN 1 See Section 5.1.1
AS_PATH 2 See Section 5.1.2
NEXT_HOP 3 See Section 5.1.3
MULTI_EXIT_DISC 4 See Section 5.1.4
LOCAL_PREF 5 See Section 5.1.5
ATOMIC_AGGREGATE 6 See Section 5.1.6
AGGREGATOR 7 See Section 5.1.7
名前値の定義---- ----- ---------- _経路2が、次のセクション5.1.2_ホップ3が、セクション5.1.3マルチ_出口_ディスク4が、セクション5.1.4の地方の_PREF5が、セクション5.1.5の原子_集合6が、セクション5.1.6アグリゲータ7がセクション5.1.7を見るのを見るのを見るのを見るのを見るのを見るとき、発生源1はセクション5.1.1を見ます。
Future assignments are to be made using either the Standards Action process defined in [RFC2434], or the Early IANA Allocation process defined in [RFC4020]. Assignments consist of a name and the value.
将来の課題は[RFC2434]で定義されたStandards Actionプロセスか[RFC4020]で定義されたEarly IANA Allocationプロセスのどちらかを使用することで作られていることです。 課題は名前と価値から成ります。
The BGP NOTIFICATION message carries an 8-bit Error Code, for which IANA has created and is maintaining a registry entitled "BGP Error Codes". This document defines the following Error Codes:
BGP NOTIFICATIONメッセージは8ビットのError Codeを運びます、IANAにはあるものが「BGPエラーコード」の権利を与えられた登録を作成されて、維持しているので。 このドキュメントは以下のError Codesを定義します:
Name Value Definition
------------ ----- ----------
Message Header Error 1 Section 6.1
OPEN Message Error 2 Section 6.2
UPDATE Message Error 3 Section 6.3
Hold Timer Expired 4 Section 6.5
Finite State Machine Error 5 Section 6.6
Cease 6 Section 6.7
名前値の定義------------ ----- ---------- メッセージヘッダー誤り1部6.1 開いているメッセージ誤り2部6.2 アップデートメッセージ誤り3部6.3 保持のタイマの満期の4部分6.5有限状態機械誤り5部6.6は6部6.7をやめます。
Rekhter, et al. Standards Track [Page 99] RFC 4271 BGP-4 January 2006
Rekhter、他 標準化過程[99ページ]RFC4271BGP-2006年1月4日
Future assignments are to be made using either the Standards Action process defined in [RFC2434], or the Early IANA Allocation process defined in [RFC4020]. Assignments consist of a name and the value.
将来の課題は[RFC2434]で定義されたStandards Actionプロセスか[RFC4020]で定義されたEarly IANA Allocationプロセスのどちらかを使用することで作られていることです。 課題は名前と価値から成ります。
The BGP NOTIFICATION message carries an 8-bit Error Subcode, where each Subcode has to be defined within the context of a particular Error Code, and thus has to be unique only within that context.
BGP NOTIFICATIONメッセージは8ビットのError Subcodeを運びます。それぞれのSubcodeはそこで特定のError Codeの文脈の中で定義されなければならなくて、その結果、その文脈だけの中で特有でなければなりません。
IANA has created and is maintaining a set of registries, "Error Subcodes", with a separate registry for each BGP Error Code. Future assignments are to be made using either the Standards Action process defined in [RFC2434], or the Early IANA Allocation process defined in [RFC4020]. Assignments consist of a name and the value.
IANAには、作成されて、維持が1セットの登録、それぞれのための別々の登録がある「誤り部分符号」であるというBGP Error Codeがあります。 将来の課題は[RFC2434]で定義されたStandards Actionプロセスか[RFC4020]で定義されたEarly IANA Allocationプロセスのどちらかを使用することで作られていることです。 課題は名前と価値から成ります。
This document defines the following Message Header Error subcodes:
このドキュメントは以下のMessage Header Error部分符号を定義します:
Name Value Definition
-------------------- ----- ----------
Connection Not Synchronized 1 See Section 6.1
Bad Message Length 2 See Section 6.1
Bad Message Type 3 See Section 6.1
名前値の定義-------------------- ----- ---------- 接続連動していない1は、セクション6.1 悪いメッセージ長2が、セクション6.1 悪いメッセージタイプ3がセクション6.1を見るのを見るのを見ます。
This document defines the following OPEN Message Error subcodes:
このドキュメントは以下のオープンMessage Error部分符号を定義します:
Name Value Definition
-------------------- ----- ----------
Unsupported Version Number 1 See Section 6.2
Bad Peer AS 2 See Section 6.2
Bad BGP Identifier 3 See Section 6.2
Unsupported Optional Parameter 4 See Section 6.2
[Deprecated] 5 See Appendix A
Unacceptable Hold Time 6 See Section 6.2
名前値の定義-------------------- ----- ---------- 2が、セクション6.2 悪いBGP識別子3が、セクション6.2 サポートされない任意のパラメタ4が、セクション6.2の[推奨しない]の5が6がセクション6.2を見る容認できない保持時間に付録を見るのを見るのを見るのを見るとき、サポートされないバージョンNo.1はセクションの6.2の悪い同輩を見ます。
This document defines the following UPDATE Message Error subcodes:
このドキュメントは以下のUPDATE Message Error部分符号を定義します:
Name Value Definition
-------------------- --- ----------
Malformed Attribute List 1 See Section 6.3
Unrecognized Well-known Attribute 2 See Section 6.3
Missing Well-known Attribute 3 See Section 6.3
Attribute Flags Error 4 See Section 6.3
Attribute Length Error 5 See Section 6.3
Invalid ORIGIN Attribute 6 See Section 6.3
[Deprecated] 7 See Appendix A
Invalid NEXT_HOP Attribute 8 See Section 6.3
Optional Attribute Error 9 See Section 6.3
Invalid Network Field 10 See Section 6.3
Malformed AS_PATH 11 See Section 6.3
名前値の定義-------------------- --- ---------- 奇形の属性リスト1は認識されていないよく知られる属性2が、よく知られる属性3を逃すセクション6.3が、セクション6.3 誤り4が、セクション6.3 属性長さの誤り5が、セクション6.3 無効の発生源属性6が、セクション6.3の[推奨しない]の7が、付録のA無効のネクスト_ホップ属性8が、セクション6.3 任意の属性誤り9が、セクション6.3 無効のネットワーク分野10が、_経路11としての奇形のセクション6.3が見るのを見るのを見るのを見るのを見るのを見るのを見るのを見る属性旗が6.3に区分するのを見るのを見るセクション6.3を見ます。
Rekhter, et al. Standards Track [Page 100] RFC 4271 BGP-4 January 2006
Rekhter、他 標準化過程[100ページ]RFC4271BGP-2006年1月4日
Normative References
引用規格
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September
1981.
[RFC791] ポステル、J.、「インターネットプロトコル」、STD5、RFC791、1981年9月。
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC
793, September 1981.
[RFC793] ポステル、J.、「通信制御プロトコル」、STD7、RFC793、1981年9月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5
Signature Option", RFC 2385, August 1998.
[RFC2385] ヘファーナン、A.、「TCP MD5 Signature Optionを通したBGPセッションズの保護」、RFC2385、1998年8月。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[RFC2434]Narten、T.とH.Alvestrand、「RFCsにIANA問題部に書くためのガイドライン」BCP26、RFC2434(1998年10月)。
Informative References
有益な参照
[RFC904] Mills, D., "Exterior Gateway Protocol formal
specification", RFC 904, April 1984.
[RFC904] 工場、D.、「外のゲートウェイプロトコル形式仕様」、RFC904、1984年4月。
[RFC1092] Rekhter, J., "EGP and policy based routing in the new
NSFNET backbone", RFC 1092, February 1989.
[RFC1092] Rekhter、J.、「EGPと方針は新しいNSFNETバックボーンにおけるルーティングを基礎づけた」RFC1092、1989年2月。
[RFC1093] Braun, H., "NSFNET routing architecture", RFC 1093,
February 1989.
[RFC1093] ブラウン、H.、「NSFNETルーティングアーキテクチャ」、RFC1093、1989年2月。
[RFC1105] Lougheed, K. and Y. Rekhter, "Border Gateway Protocol
(BGP)", RFC 1105, June 1989.
[RFC1105]ロッキードとK.とY.Rekhter、「ボーダ・ゲイトウェイ・プロトコル(BGP)」、RFC1105 1989年6月。
[RFC1163] Lougheed, K. and Y. Rekhter, "Border Gateway Protocol
(BGP)", RFC 1163, June 1990.
[RFC1163]ロッキードとK.とY.Rekhter、「ボーダ・ゲイトウェイ・プロトコル(BGP)」、RFC1163 1990年6月。
[RFC1267] Lougheed, K. and Y. Rekhter, "Border Gateway Protocol 3
(BGP-3)", RFC 1267, October 1991.
[RFC1267]ロッキードとK.とY.Rekhter、「ボーダ・ゲイトウェイ・プロトコル3(BGP-3)」、RFC1267 1991年10月。
[RFC1771] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-
4)", RFC 1771, March 1995.
[RFC1771] RekhterとY.とT.李、「ボーダ・ゲイトウェイ・プロトコル4(BGP4)」、RFC1771、1995年3月。
[RFC1772] Rekhter, Y. and P. Gross, "Application of the Border
Gateway Protocol in the Internet", RFC 1772, March 1995.
[RFC1772]RekhterとY.とP.グロス、「インターネットでのボーダ・ゲイトウェイ・プロトコルの応用」、RFC1772、1995年3月。
[RFC1518] Rekhter, Y. and T. Li, "An Architecture for IP Address
Allocation with CIDR", RFC 1518, September 1993.
[RFC1518] RekhterとY.とT.李、「CIDRとのIPアドレス配分のためのアーキテクチャ」、RFC1518、1993年9月。
Rekhter, et al. Standards Track [Page 101] RFC 4271 BGP-4 January 2006
Rekhter、他 標準化過程[101ページ]RFC4271BGP-2006年1月4日
[RFC1519] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Classless
Inter-Domain Routing (CIDR): an Address Assignment and
Aggregation Strategy", RFC 1519, September 1993.
[RFC1519] フラー、V.、李、T.、ユー、J.、およびK.Varadhan、「以下を掘る(CIDR)階級のない相互ドメイン」 「アドレス課題と集合戦略」、RFC1519、9月1993日
[RFC1930] Hawkinson, J. and T. Bates, "Guidelines for creation,
selection, and registration of an Autonomous System (AS)",
BCP 6, RFC 1930, March 1996.
[RFC1930]Hawkinson、J.とT.ベイツ、「Autonomous System(AS)の作成、選択、および登録のためのガイドライン」BCP6、RFC1930(1996年3月)。
[RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities
Attribute", RFC 1997, August 1996.
[RFC1997] チャンドラとR.とTraina、P.とT.李、「BGP共同体属性」、RFC1997、1996年8月。
[RFC2439] Villamizar, C., Chandra, R., and R. Govindan, "BGP Route
Flap Damping", RFC 2439, November 1998.
[RFC2439] VillamizarとC.とチャンドラ、R.とR.Govindan、「BGPルートフラップ湿気」、RFC2439、1998年11月。
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS Field)
in the IPv4 and IPv6 Headers", RFC 2474, December 1998.
[RFC2474] ニコルズ、K.、ブレーク、S.、ベイカー、F.、およびD.黒、「IPv4とIPv6ヘッダーとの差別化されたサービス分野(DS分野)の定義」、RFC2474(1998年12月)。
[RFC2796] Bates, T., Chandra, R., and E. Chen, "BGP Route Reflection
- An Alternative to Full Mesh IBGP", RFC 2796, April 2000.
[RFC2796] ベイツ、T.、チャンドラ、R.、およびE.チェン、「BGPは反射を発送します--完全なメッシュIBGPへの代替手段」、RFC2796、2000年4月。
[RFC2858] Bates, T., Rekhter, Y., Chandra, R., and D. Katz,
"Multiprotocol Extensions for BGP-4", RFC 2858, June 2000.
[RFC2858] ベイツ、T.、Rekhter、Y.、チャンドラ、R.、およびD.キャッツ、「BGP-4インチのためのMultiprotocol拡張子、RFC2858、2000年6月。」
[RFC3392] Chandra, R. and J. Scudder, "Capabilities Advertisement
with BGP-4", RFC 3392, November 2002.
[RFC3392] チャンドラとR.とJ.Scudder、「BGP-4インチがある能力広告、RFC3392、2002年11月。」
[RFC2918] Chen, E., "Route Refresh Capability for BGP-4", RFC 2918,
September 2000.
[RFC2918]チェン、E.、「ルートは2000年9月にBGP-4インチ、RFC2918のために能力をリフレッシュします」。
[RFC3065] Traina, P., McPherson, D., and J. Scudder, "Autonomous
System Confederations for BGP", RFC 3065, February 2001.
2001年2月の[RFC3065]TrainaとP.とマクファーソン、D.とJ.Scudder、「BGPのための自律システム同盟者」RFC3065。
[RFC3562] Leech, M., "Key Management Considerations for the TCP MD5
Signature Option", RFC 3562, July 2003.
[RFC3562] ヒル、M.、「TCP MD5署名オプションのためのKey Management問題」、RFC3562、2003年7月。
[IS10747] "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.
[IS10747]、「情報処理システム(システムの間のテレコミュニケーションと情報交換)が相互ドメインRouteing情報の交換のために推進をサポートする中間システムの中で議定書を作る、ISO8473PDUs、」、ISO/IEC IS10747、1993
[RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", RFC
4272, January 2006
[RFC4272] マーフィー、S.、「BGPセキュリティの脆弱性分析」、RFC4272、2006年1月
[RFC4020] Kompella, K. and A. Zinin, "Early IANA Allocation of
Standards Track Code Points", BCP 100, RFC 4020, February
2005.
[RFC4020]Kompella、K.とA.ジニン、「標準化過程コード・ポイントの早めのIANA配分」BCP100、2005年2月のRFC4020。
Rekhter, et al. Standards Track [Page 102] RFC 4271 BGP-4 January 2006
Rekhter、他 標準化過程[102ページ]RFC4271BGP-2006年1月4日
Editors' Addresses
エディタのアドレス
Yakov Rekhter Juniper Networks
ヤコフRekhter杜松ネットワーク
EMail: yakov@juniper.net
メール: yakov@juniper.net
Tony Li
トニー・李
EMail: tony.li@tony.li
メール: tony.li@tony.li
Susan Hares NextHop Technologies, Inc. 825 Victors Way Ann Arbor, MI 48108
スーザン野兎のNextHop技術Inc.825勝者道、アナーバー、MI 48108
Phone: (734)222-1610 EMail: skh@nexthop.com
以下に電話をしてください。 (734)222-1610 メールしてください: skh@nexthop.com
Rekhter, et al. Standards Track [Page 103] RFC 4271 BGP-4 January 2006
Rekhter、他 標準化過程[103ページ]RFC4271BGP-2006年1月4日
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(2006)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Rekhter, et al. Standards Track [Page 104]
Rekhter、他 標準化過程[104ページ]
一覧
スポンサーリンク
