[要約] RFC 4271は、BGP-4（Border Gateway Protocol 4）の仕様を定義しており、インターネットのルーティングプロトコルとして使用されます。このRFCの目的は、異なる自治システム間の経路情報の交換と選択を効率的に行うための標準化を提供することです。
Network Working Group Y. Rekhter, Ed.
Request for Comments: 4271 T. Li, Ed.
Obsoletes: 1771 S. Hares, Ed.
Category: Standards Track January 2006
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.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
Copyright（C）The Internet Society（2006）。
Abstract
概要
This document discusses the Border Gateway Protocol (BGP), which is an inter-Autonomous System routing protocol.
このドキュメントでは、自律システム間ルーティングプロトコルであるボーダーゲートウェイプロトコル（BGP）について説明します。
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システムとネットワーク到達可能性情報を交換することです。このネットワーク到達可能性情報には、到達可能性情報が通過する自律システム（AS）のリストに関する情報が含まれています。この情報は、ルーティングループがプルーニングされる可能性があるこの到達可能性の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.
BGP-4は、クラスレスドメイン間ルーティング（CIDR）をサポートするための一連のメカニズムを提供します。これらのメカニズムには、一連の宛先をIPプレフィックスとしてアドバタイズするためのサポートが含まれ、BGP内のネットワーク「クラス」の概念が排除されます。 BGP-4には、ASパスの集約など、ルートの集約を可能にするメカニズムも導入されています。
This document obsoletes RFC 1771.
このドキュメントはRFC 1771を廃止します。
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
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
The Border Gateway Protocol (BGP) is an inter-Autonomous System routing protocol.
ボーダーゲートウェイプロトコル（BGP）は、自律システム間のルーティングプロトコルです。
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システムとネットワーク到達可能性情報を交換することです。このネットワーク到達可能性情報には、到達可能性情報が通過する自律システム（AS）のリストに関する情報が含まれています。この情報は、この到達可能性の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.
BGP-4は、クラスレスドメイン間ルーティング（CIDR）[RFC1518、RFC1519]をサポートするための一連のメカニズムを提供します。これらのメカニズムには、一連の宛先をIPプレフィックスとして通知し、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ヘッダーに含まれる宛先アドレスのみに基づいてパケットを転送することを前提としています。これは、BGPを使用して実施できる（および実施できない）ポリシー決定のセットを反映しています。 BGPは、宛先ベースの転送パラダイムに準拠するポリシーのみをサポートできます。
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-In Adj-RIBs-Inには、ピアによってローカル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-Out Adj-RIBs-Outには、ローカルスピーカーの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 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）自律システムの古典的な定義は、内部ゲートウェイプロトコル（IGP）と共通メトリックを使用してAS内でパケットをルーティングする方法を決定し、AS間を使用して、単一の技術管理下にある一連のルーターです。パケットを他のASにルーティングする方法を決定するルーティングプロトコル。この古典的な定義が開発されて以来、単一のASが複数のIGPを使用し、場合によってはAS内で複数のメトリックセットを使用することが一般的になりました。自律システムという用語の使用は、複数のIGPおよびメトリックが使用されている場合でも、ASの管理が他のASに対して単一の一貫した内部ルーティングプランを持っているように見え、到達可能な宛先の一貫した図を提示するという事実を強調していますそれを通して。
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 ID BGPメッセージの送信者のBGP IDを示す4オクテットの符号なし整数。特定のBGPスピーカーは、そのBGP識別子の値を、そのBGPスピーカーに割り当てられたIPアドレスに設定します。 BGP IDの値は起動時に決定され、すべてのローカルインターフェイスとBGPピアで同じです。
BGP speaker A router that implements BGP.
BGPスピーカーBGPを実装するルーター。
EBGP External BGP (BGP connection between external peers).
EBGP外部BGP（外部ピア間のBGP接続）。
External peer Peer that is in a different Autonomous System than the local system.
ローカルシステムとは異なる自律システムにある外部ピアピア。
Feasible route An advertised route that is available for use by the recipient.
実行可能なルート受信者が使用できるアドバタイズされたルート。
IBGP Internal BGP (BGP connection between internal peers).
IBGP内部BGP（内部ピア間のBGP接続）。
Internal peer Peer that is in the same Autonomous System as the local system.
ローカルシステムと同じ自律システム内にある内部ピアピア。
IGP Interior Gateway Protocol - a routing protocol used to exchange routing information among routers within a single Autonomous System.
IGP Interior Gateway Protocol-単一の自律システム内のルーター間でルーティング情報を交換するために使用されるルーティングプロトコル。
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スピーカーの決定プロセスによって選択されたルートが含まれています。
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 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.
ルート一連の宛先をそれらの宛先へのパスの属性とペアにする情報の単位。宛先のセットは、UPDATEメッセージのネットワーク層到達可能性情報（NLRI）フィールドに含まれる1つのIPアドレスプレフィックスにIPアドレスが含まれているシステムです。パスは、同じUPDATEメッセージのパス属性フィールドで報告される情報です。
RIB Routing Information Base.
RIBルーティング情報ベース。
Unfeasible route A previously advertised feasible route that is no longer available for use.
実行不可能なルート以前にアドバタイズされた、使用できなくなった実行可能なルート。
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」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [RFC2119]で説明されているように解釈されます。
This document was originally published as [RFC1267] in October 1991, jointly authored by Kirk Lougheed and Yakov Rekhter.
この文書は、1991年10月に[RFC1267]として最初に発行され、Kirk LougheedとYakov Rekhterによって共同執筆されました。
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）に貢献してくれたGuy Almes、Len Bosack、Jeffrey C. Honigに感謝の意を表します。
We would like to specially acknowledge numerous contributions by Dennis Ferguson to the earlier version of this document.
このドキュメントの以前のバージョンに対するDennis Fergusonの多数の貢献に特に感謝します。
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）をレビューするために彼が集めたレビュー担当者のチームにも感謝します。このチームは、デボラエストリン、ミロメディン、ジョンモイ、ラディアパールマン、マーサステーンストラップ、マイクセントジョンズ、ポールツチヤで構成され、タフネス、プロ意識、および礼儀の強い組み合わせで行動しました。
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.
このドキュメントの特定のセクションは、BGPのOSI版であるIDRP [IS10747]から大きく借用したものです。そのためには、ライマンチャピンが議長を務めるANSI X3S3.3グループと、そのグループのIDRP編集者であったCharles Kunzingerにクレジットを与える必要があります。
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.
Benjamin Abarbanel、Enke Chen、Edward Crabbe、Mike Craren、Vincent Gillet、Eric Grey、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、Alex Zininのコメント。
We would like to specially acknowledge Andrew Lange for his help in preparing the final version of this document.
このドキュメントの最終版を作成するにあたって、Andrew Lange氏のご協力に特に感謝いたします。
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ワーキンググループのメンバー全員に、このドキュメントへのアイデアとサポートを感謝します。
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）は、自律システム間のルーティングプロトコルです。 EGP（[RFC904]で定義）で得られた経験とNSFNETバックボーン（[RFC1092]および[RFC1093]で説明）でのEGPの使用に基づいて構築されています。 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システムとネットワーク到達可能性情報を交換することです。このネットワーク到達可能性情報には、到達可能性情報が通過する自律システム（AS）のリストに関する情報が含まれています。この情報は、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ルートであり、転送で使用されます）。他のすべてのケースは、このドキュメントの範囲外です。
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 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.
BGPを介して交換されるルーティング情報は、宛先ベースの転送パラダイムのみをサポートします。これは、ルーターがパケットのIPヘッダーに含まれる宛先アドレスのみに基づいてパケットを転送することを前提としています。これは、BGPを使用して実施できる（および実施できない）ポリシー決定のセットを反映しています。一部のポリシーは宛先ベースの転送パラダイムではサポートできないため、送信元ルーティング（別名明示的ルーティング）などの手法を適用する必要があることに注意してください。このようなポリシーは、BGPを使用して強制することもできません。たとえば、BGPは、あるASが近隣の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は、クラスレスドメイン間ルーティング（CIDR）[RFC1518、RFC1519]をサポートするための新しいメカニズムセットを提供します。これらのメカニズムには、宛先のセットをIPプレフィックスとしてアドバタイズするためのサポートと、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.
このドキュメントでは、全体を通じて「自律システム」（AS）という用語を使用します。自律システムの古典的な定義は、内部ゲートウェイプロトコル（IGP）と共通メトリックを使用してAS内でパケットをルーティングする方法を決定し、AS間ルーティングプロトコルを使用して方法を決定する、単一の技術管理下の一連のルーターです。パケットを他のASにルーティングします。この古典的な定義が開発されて以来、単一のASが複数のIGPを使用し、場合によってはAS内で複数のメトリックセットを使用することが一般的になりました。自律システムという用語の使用は、複数のIGPとメトリックが使用されている場合でも、ASの管理が他のASに単一の一貫した内部ルーティングプランを持っているように見え、到達可能な宛先の一貫した図を提示するという事実を強調していますそれ。
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.
2つのシステム間でTCP接続が形成されます。メッセージを交換して、接続パラメーターを開いて確認します。
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-Ribs-Out（3.2を参照）と呼ばれる、エクスポートポリシーによって許可されるBGPルーティングテーブルの一部です。ルーティングテーブルが変更されると、増分更新が送信されます。 BGPでは、ルーティングテーブルを定期的に更新する必要はありません。ローカルポリシーの変更がBGP接続をリセットせずに正しい効果を発揮できるようにするには、BGPスピーカーは（a）接続中にすべてのピアによってアドバタイズされたルートの現在のバージョンを保持する必要があります（b） Route Refresh拡張[RFC2918]を利用してください。
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スピーカーがあり、他のASに中継サービスを提供している場合は、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プロトコルの基本的な動作について説明します。この動作は、拡張仕様によって変更される可能性があります。プロトコルが拡張されると、新しい動作は拡張仕様に完全に文書化されます。
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.
このプロトコルでは、ルートは、一連の宛先とそれらの宛先へのパスの属性をペアにする情報の単位として定義されます。宛先のセットは、UPDATEメッセージのネットワーク層到達可能性情報（NLRI）フィールドで運ばれる1つのIPアドレスプレフィックスに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メッセージのNLRIフィールドに複数のプレフィックスを含めることにより、単一のUPDATEメッセージでアドバタイズできます。
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.
ルートはルーティング情報ベース（RIB）に保存されます。つまり、セクション3.2で説明されているように、Adj-RIBs-In、Loc-RIB、およびAdj-RIBs-Outです。
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スピーカーが以前に受信したルートをアドバタイズすることを選択した場合、ピアにアドバタイズする前に、ルートのパス属性を追加または変更できます（MAY）。
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) 以前にアドバタイズされたルートの宛先を表すIPプレフィックスは、UPDATEメッセージのWITHDRAWN ROUTESフィールドでアドバタイズできるため、関連付けられたルートを使用不可としてマークします。
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.
ルートの属性を変更するには、置換ルートをアドバタイズします。置換ルートは新しい（変更された）属性を持ち、元のルートと同じアドレスプレフィックスを持っています。
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-RIBs-In：Adj-RIBs-Inは、他のBGPスピーカーから受信したインバウンドUPDATEメッセージから学習したルーティング情報を保存します。それらの内容は、意思決定プロセスへの入力として使用可能なルートを表します。
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-RIB：Loc-RIBには、Adj-RIBs-Inに含まれるルーティング情報にローカルポリシーを適用することによってBGPスピーカーが選択したローカルルーティング情報が含まれています。これらは、ローカルBGPスピーカーが使用するルートです。これらの各ルートのネクストホップは、ローカルBGPスピーカーのルーティングテーブルを介して解決できる必要があります。
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-RIBs-Out：Adj-RIBs-Outは、ピアへのアドバタイズのためにローカルBGPスピーカーが選択した情報を格納します。 Adj-RIBs-Outに格納されたルーティング情報は、ローカル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 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).
要約すると、Adj-RIBs-Inには、ピアによってローカルBGPスピーカーにアドバタイズされた未処理のルーティング情報が含まれています。 Loc-RIBには、ローカルBGPスピーカーの決定プロセスによって選択されたルートが含まれています。 Adj-RIBs-Outは、（ローカルスピーカーの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-In、Loc-RIB、およびAdj-RIBs-Outを区別しますが、これは実装がルーティング情報の3つの別個のコピーを維持する必要があることを意味することも要求することもありません。実装の選択（たとえば、情報の3つのコピーとポインター付きの1つのコピー）は、プロトコルによって制約されません。
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スピーカーがパケットの転送（またはパケット転送に使用される転送テーブルの作成）に使用するルーティング情報は、ルーティングテーブルに保持されます。ルーティングテーブルは、直接接続されたネットワークへのルート、静的ルート、IGPプロトコルから学習したルート、およびBGPから学習したルートを蓄積します。特定のBGPルートをルーティングテーブルにインストールする必要があるかどうか、およびBGPルートが別のソースによってインストールされた同じ宛先へのルートをオーバーライドする必要があるかどうかは、ローカルポリシーの決定であり、このドキュメントでは指定しません。実際のパケット転送に加えて、ルーティングテーブルは、BGPアップデートで指定されたネクストホップアドレスの解決に使用されます（セクション5.1.3を参照）。
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).
BGPメッセージはTCP接続を介して送信されます。メッセージは、完全に受信された後でのみ処理されます。最大メッセージサイズは4096オクテットです。この最大メッセージサイズをサポートするには、すべての実装が必要です。送信できる最小のメッセージは、データ部分のないBGPヘッダー（19オクテット）で構成されます。
All multi-octet fields are in network byte order.
すべてのマルチオクテットフィールドは、ネットワークバイトオーダーです。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Marker:
マーカー：
This 16-octet field is included for compatibility; it MUST be set to all ones.
この16オクテットフィールドは互換性のために含まれています。すべて1に設定する必要があります。
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オクテットの符号なし整数は、メッセージの全長（オクテットのヘッダーを含む）を示します。したがって、TCPストリーム内の次の（のマーカーフィールド）メッセージを見つけることができます。長さフィールドの値は、常に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-キープアライブ
[RFC2918] defines one more type code.
[RFC2918]はもう1つのタイプコードを定義しています。
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接続が確立された後、両側から送信される最初のメッセージはOPENメッセージです。 OPENメッセージが受け入れられる場合、OPENを確認するKEEPALIVEメッセージが返送されます。
In addition to the fixed-size BGP header, the OPEN message contains the following fields:
固定サイズのBGPヘッダーに加えて、OPENメッセージには次のフィールドが含まれます。
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) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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オクテットの符号なし整数は、送信者の自律システム番号を示します。
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 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.
この2オクテットの符号なし整数は、送信者がホールドタイマーの値を提案する秒数を示します。 OPENメッセージを受信すると、BGPスピーカーは、設定されたホールドタイムとOPENメッセージで受信したホールドタイムの小さい方を使用して、ホールドタイマーの値を計算する必要があります。保持時間はゼロまたは少なくとも3秒でなければなりません。実装は、ホールドタイムに基づいて接続を拒否する場合があります。計算された値は、送信者からの連続する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 IDを示します。特定のBGPスピーカーは、そのBGP識別子の値を、そのBGPスピーカーに割り当てられているIPアドレスに設定します。 BGP IDの値は起動時に決定され、すべてのローカルインターフェイスと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:
オプションのパラメーター：
This field contains a list of optional parameters, in which each parameter is encoded as a <Parameter Type, Parameter Length, Parameter Value> triplet.
このフィールドには、オプションのパラメーターのリストが含まれます。各パラメーターは、<パラメータータイプ、パラメーター長、パラメーター値>トリプレットとしてエンコードされます。
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)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
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.
パラメータタイプは、個々のパラメータを明確に識別する1オクテットのフィールドです。パラメータ長は、1オクテットのフィールドで、オクテット単位のパラメータ値フィールドの長さが含まれています。パラメータ値は可変長フィールドであり、パラメータタイプフィールドの値に従って解釈されます。
[RFC3392] defines the Capabilities Optional Parameter.
[RFC3392]は、機能のオプションパラメータを定義します。
The minimum length of the OPEN message is 29 octets (including the message header).
OPENメッセージの最小長は29オクテット（メッセージヘッダーを含む）です。
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 information loops and some other anomalies may be detected and removed from inter-AS routing.
UPDATEメッセージは、BGPピア間でルーティング情報を転送するために使用されます。 UPDATEメッセージの情報を使用して、さまざまな自律システムの関係を表すグラフを作成できます。説明するルールを適用することにより、ルーティング情報のループやその他の異常が検出され、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) |
+-----------------------------------------------------+
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フィールドの全長をオクテットで示します。その値により、以下に示すように、ネットワーク層到達可能性情報フィールドの長さを決定できます。
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アドレスプレフィックスは、<length、prefix>形式の2タプルとしてエンコードされます。そのフィールドについては以下で説明します。
+---------------------------+
| Length (1 octet) |
+---------------------------+
| Prefix (variable) |
+---------------------------+
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).
長さフィールドは、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オクテットの符号なし整数は、パス属性フィールドの全長をオクテットで示します。その値により、ネットワーク層到達可能性フィールドの長さを以下のように決定できます。
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は、ネットワーク層到達可能性情報フィールドもパス属性フィールドもこの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メッセージに存在します。各パス属性は、可変長の3つの<属性タイプ、属性長、属性値>です。
Attribute Type is a two-octet field that consists of the Attribute Flags octet, followed by the Attribute Type Code octet.
属性タイプは、属性フラグオクテットと、それに続く属性タイプコードオクテットで構成される2オクテットのフィールドです。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attr. Flags |Attr. Type Code|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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).
属性フラグオクテットの上位ビット（ビット0）は、オプションビットです。属性がオプション（1に設定されている場合）か、既知（0に設定されている場合）かを定義します。
The second high-order bit (bit 1) of the Attribute Flags octet is the Transitive bit. It defines whether an optional attribute is transitive (if set to 1) or non-transitive (if set to 0).
属性フラグオクテットの2番目の上位ビット（ビット1）は推移ビットです。これは、オプション属性が推移的（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.
属性フラグオクテットの3番目の上位ビット（ビット2）は部分ビットです。オプションの推移属性に含まれる情報が部分的（1に設定されている場合）または完全（0に設定されている場合）であるかどうかを定義します。既知の属性およびオプションの非推移的属性の場合、部分ビットを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).
属性フラグオクテットの4番目の上位ビット（ビット3）は、拡張長ビットです。属性の長さが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.
属性フラグオクテットの下位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で説明します。
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.
属性フラグオクテットの拡張長ビットが0に設定されている場合、パス属性の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.
属性フラグオクテットの拡張長ビットが1に設定されている場合、パス属性の3番目と4番目のオクテットには、オクテット単位の属性データの長さが含まれます。
The remaining octets of the Path Attribute represent the attribute value and are interpreted according to the Attribute Flags and the Attribute Type Code. The supported Attribute Type Codes, and their attribute values and uses are as follows:
パス属性の残りのオクテットは属性値を表し、属性フラグと属性タイプコードに従って解釈されます。サポートされている属性タイプコード、およびそれらの属性値と用途は次のとおりです。
a) ORIGIN (Type Code 1):
a) ORIGIN（タイプコード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
0 IGP-ネットワークレイヤー到達可能性情報は発信元ASの内部にあります
1 EGP - Network Layer Reachability Information learned via the EGP protocol [RFC904]
1 EGP-EGPプロトコルを介して学習されたネットワーク層到達可能性情報[RFC904]
2 INCOMPLETE - Network Layer Reachability Information learned by some other means
2不完全-他の手段で学習したネットワーク層到達可能性情報
Usage of this attribute is defined in 5.1.1.
この属性の使用法は5.1.1で定義されています。
b) AS_PATH (Type Code 2):
b) AS_PATH（タイプコード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パスセグメントは、3つの<パスセグメントタイプ、パスセグメント長、パスセグメント値>で表されます。
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 AS_SET：UPDATEメッセージ内のルートが通過した無順序のASセット
2 AS_SEQUENCE: ordered set of ASes a route in the UPDATE message has traversed
2 AS_SEQUENCE：UPDATEメッセージ内のルートが通過したASの順序付けられたセット
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オクテットの長さフィールドで、パスセグメント値フィールドのASの数（オクテットの数ではない）を含みます。
The path segment value field contains one or more AS numbers, each encoded as a 2-octet length field.
パスセグメント値フィールドには1つ以上のAS番号が含まれ、それぞれが2オクテットの長さフィールドとしてエンコードされます。
Usage of this attribute is defined in 5.1.2.
この属性の使用法は5.1.2で定義されています。
c) NEXT_HOP (Type Code 3):
c) NEXT_HOP（タイプコード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 Informationフィールドにリストされている宛先へのネクストホップとして使用する必要があるルーターの（ユニキャスト）IPアドレスを定義します。
Usage of this attribute is defined in 5.1.3.
この属性の使用法は5.1.3で定義されています。
d) MULTI_EXIT_DISC (Type Code 4):
d) MULTI_EXIT_DISC（タイプコード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スピーカーの決定プロセスによって使用される場合があります。
Usage of this attribute is defined in 5.1.4.
この属性の使用法は5.1.4で定義されています。
e) LOCAL_PREF (Type Code 5):
e) LOCAL_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) ATOMIC_AGGREGATE（タイプコード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) AGGREGATOR（タイプコード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のオプションの推移属性です。この属性には、集約ルートを形成した最後のAS番号（2オクテットとしてエンコード）と、その後に集約ルートを形成したBGPスピーカーのIPアドレス（4オクテットとしてエンコード）が含まれます。これは、スピーカーのBGP識別子に使用されるアドレスと同じアドレスにする必要があります（SHOULD）。
Usage of this attribute is defined in 5.1.7.
この属性の使用法は5.1.7で定義されています。
Network Layer Reachability Information:
ネットワーク層到達可能性情報：
This variable length field contains a list of IP address prefixes. The length, in octets, of the Network Layer Reachability Information is not encoded explicitly, but can be calculated as:
この可変長フィールドには、IPアドレスプレフィックスのリストが含まれています。ネットワーク層到達可能性情報の長さ（オクテット単位）は明示的にエンコードされていませんが、次のように計算できます。
UPDATE message Length - 23 - Total Path Attributes Length - Withdrawn Routes Length
UPDATEメッセージの長さ-23-パス属性の長さの合計-撤回されたルートの長さ
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メッセージの長さは、固定サイズのBGPヘッダーにエンコードされた値、合計パス属性の長さ、および撤回されたルートの長さは、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:
到達可能性情報は、<length、prefix>形式の1つ以上の2タプルとしてエンコードされます。フィールドについては以下で説明します。
+---------------------------+
| Length (1 octet) |
+---------------------------+
| Prefix (variable) |
+---------------------------+
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).
長さフィールドは、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オクテットです。固定ヘッダーの19オクテット+撤回ルート長の2オクテット+総パス属性長の2オクテット（撤回ルートの長さの値は0で、総パスの値です）属性の長さは0です）。
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メッセージは、サービスから削除される複数のルートをリストできます。そのような各ルートは、宛先（IPプレフィックスとして表されます）によって識別されます。これにより、BGPスピーカー-以前にアドバタイズされた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メッセージは、サービスから撤回されるルートのみをアドバタイズする場合があります。その場合、メッセージにはパス属性またはネットワーク層到達可能性情報は含まれません。逆に、実行可能なルートのみをアドバタイズする場合があります。その場合、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.
UPDATEメッセージには、WITHDRAWN ROUTESフィールドとNetwork Layer Reachability Informationフィールドに同じアドレスプレフィックスを含めないでください。ただし、BGPスピーカーはこの形式でUPDATEメッセージを処理できる必要があります。 BGPスピーカーは、この形式のUPDATEメッセージを、WITHDRAWN ROUTESにアドレスプレフィックスが含まれていないかのように処理する必要があります（SHOULD）。
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ベースのキープアライブメカニズムを使用して、ピアが到達可能かどうかを判断しません。代わりに、KEEPALIVEメッセージがピア間で交換され、ホールドタイマーが期限切れにならないようにします。 KEEPALIVEメッセージ間の妥当な最大時間は、ホールドタイム間隔の3分の1です。 KEEPALIVEメッセージは、1秒あたり1回よりも頻繁に送信してはなりません。実装は、保持時間間隔の関数としてKEEPALIVEメッセージを送信するレートを調整できます（MAY）。
If the negotiated Hold Time interval is zero, then periodic KEEPALIVE messages MUST NOT be sent.
ネゴシエートされた保持時間間隔がゼロの場合、定期的なKEEPALIVEメッセージを送信してはなりません（MUST NOT）。
A KEEPALIVE message consists of only the message header and has a length of 19 octets.
KEEPALIVEメッセージはメッセージヘッダーのみで構成され、長さは19オクテットです。
A NOTIFICATION message is sent when an error condition is detected. The BGP connection is closed immediately after it is sent.
エラー状態が検出されると、NOTIFICATIONメッセージが送信されます。 BGP接続は、送信後すぐに閉じられます。
In addition to the fixed-size BGP header, the NOTIFICATION message contains the following fields:
固定サイズのBGPヘッダーに加えて、NOTIFICATIONメッセージには次のフィールドが含まれます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error code | Error subcode | Data (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Error Code:
エラーコード：
This 1-octet unsigned integer indicates the type of NOTIFICATION. The following Error Codes have been defined:
この1オクテットの符号なし整数は、通知のタイプを示します。次のエラーコードが定義されています。
Error Code Symbolic Name Reference
エラーコードシンボリック名のリファレンス
1 Message Header Error Section 6.1
1メッセージヘッダーエラーセクション6.1
2 OPEN Message Error Section 6.2
2 OPENメッセージエラーセクション6.2
3 UPDATE Message Error Section 6.3
3 UPDATEメッセージエラーセクション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オクテットの符号なし整数は、報告されたエラーの性質に関するより具体的な情報を提供します。各エラーコードには、1つ以上のエラーサブコードが関連付けられている場合があります。適切なエラーサブコードが定義されていない場合、ゼロ（不特定）値がエラーサブコードフィールドに使用されます。
Message Header Error subcodes:
メッセージヘッダーエラーサブコード：
1 - Connection Not Synchronized. 2 - Bad Message Length. 3 - Bad Message Type.
1-接続が同期されていません。 2-不正なメッセージ長。 3-不正なメッセージタイプ。
OPEN Message Error subcodes:
OPENメッセージエラーのサブコード：
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-Bad Peer AS。 3-不正なBGP識別子。 4-サポートされていないオプションパラメータ。 5-[非推奨-付録Aを参照]。 6-許容できないホールドタイム。
UPDATE Message Error subcodes:
UPDATEメッセージエラーサブコード：
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-無効なORIGIN属性。 7-[非推奨-付録Aを参照]。 8-無効なNEXT_HOP属性。 9-オプションの属性エラー。 10-無効なネットワークフィールド。 11-不正なAS_PATH。
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の理由を診断するために使用されます。データフィールドの内容は、エラーコードとエラーサブコードによって異なります。詳細については、セクション6を参照してください。
Note that the length of the Data field can be determined from the message Length field by the formula:
データフィールドの長さは、メッセージの長さフィールドから次の式で決定できることに注意してください。
Message Length = 21 + Data Length
メッセージ長= 21 +データ長
The minimum length of the NOTIFICATION message is 21 octets (including message header).
NOTIFICATIONメッセージの最小長は21オクテット（メッセージヘッダーを含む）です。
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.オプションの非推移的。
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つ以上のオプション属性を含めることができます（MAY）。すべてのBGP実装がすべてのオプション属性をサポートする必要はありません。認識されないオプション属性の処理は、属性フラグオクテットのTransitiveビットの設定によって決まります。認識されない推移的なオプション属性を持つパスは受け入れられるべきです（SHOULD）。認識されない推移的なオプション属性を持つパスが受け入れられ、他のBGPピアに渡される場合、そのパスの認識されない推移的なオプション属性が、パスとともに、属性フラグオクテットセットの部分ビットを持つ他のBGPピアに渡される必要があります。 1.認識された推移的なオプション属性を持つパスが受け入れられ、他のBGPピアに渡され、属性フラグオクテットの部分ビットが以前のASによって1に設定されている場合、現在のAS。認識されない非推移的なオプション属性は、静かに無視され、他の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スピーカーによってパスに添付される場合があります。それらがオリジネーターによって付加されない場合、属性フラグオクテットの部分ビットは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.
UPDATEメッセージの送信者は、UPDATEメッセージ内のパス属性を属性タイプの昇順で並べる必要があります（SHOULD）。 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メッセージの[パス属性]フィールド内に複数回表示することはできません。
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
属性EBGP IBGP ORIGIN必須必須AS_PATH必須必須NEXT_HOP必須必須MULTI_EXIT_DISC任意の任意LOCAL_PREFセクション5.1.5を参照必須ATOMIC_AGGREGATEセクション5.1.6および9.1.4を参照任意AGGREGATOR任意
The usage of each BGP path attribute is described in the following clauses.
各BGPパス属性の使用法については、以下の節で説明します。
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属性は、関連するルーティング情報を発信するスピーカーによって生成されます。その値は他のスピーカーによって変更されるべきではありません。
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_SETまたはAS_SEQUENCEにすることができます。
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スピーカーがルートを内部ピアにアドバタイズする場合、アドバタイズスピーカーはルートに関連付けられたAS_PATH属性を変更してはなりません（SHALL NOT）。
b) When a given BGP speaker advertises the route to an external peer, the advertising speaker updates the AS_PATH attribute as follows: 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.
b) 特定のBGPスピーカーがルートを外部ピアにアドバタイズすると、アドバタイズスピーカーはAS_PATH属性を次のように更新します。1）AS_PATHの最初のパスセグメントのタイプがAS_SEQUENCEの場合、ローカルシステムは独自のAS番号を最後の要素として付加します。シーケンスの（プロトコルメッセージのオクテットの位置に対して左端の位置に配置します）。先頭に追加することによりAS_PATHセグメントでオーバーフローが発生する場合（つまり、255 ASを超える場合）、タイプAS_SEQUENCEの新しいセグメントを追加し、この新しいセグメントに独自のAS番号を追加する必要があります（SHOULD）。
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_PATHの最初のパスセグメントがタイプAS_SETである場合、ローカルシステムは、タイプAS_SEQUENCEの新しいパスセグメントをAS_PATHに追加し、そのセグメント内の独自のAS番号を含めます。
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) 発信元スピーカーは、外部ピアに送信されるすべてのUPDATEメッセージのAS_PATH属性に、タイプAS_SEQUENCEのパスセグメントの独自のAS番号を含めます。この場合、発信元スピーカーの自律システムの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属性は、長さフィールドに値0が含まれる属性です）。
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番号の追加または前置を要求するときはいつでも、ローカルシステムはAS_PATH属性にそれ自身のAS番号の複数のインスタンスを含める/前に追加してもよい（MAY）。これはローカル設定によって制御されます。
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:
NEXT_HOPは、UPDATEメッセージにリストされている宛先への次のホップとして使用する必要があるルーターのIPアドレスを定義する、よく知られた必須属性です。 NEXT_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 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).
1）内部ピアにメッセージを送信するときに、ルートがローカルで発信されていない場合、BGPスピーカーは、自身のIPアドレスをNEXT_HOPとしてアナウンスするように明示的に構成されていない限り、NEXT_HOP属性を変更してはなりません（SHOULD NOT）。ローカルピアから内部ピアへのルートをアナウンスするとき、BGPスピーカーは、アナウンスされたネットワークがスピーカーに到達できるルーターのインターフェイスアドレスをNEXT_HOPとして使用する必要があります（SHOULD）。ルートがスピーカーに直接接続されている場合、またはスピーカーがアナウンスされたネットワークに到達できるルーターのインターフェイスアドレスが内部ピアのアドレスである場合、BGPスピーカーはNEXT_HOP属性に独自のIPアドレスを使用する必要があります（SHOULD）ピアに到達するために使用されるインターフェースのアドレス）。
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スピーカーは、アナウンスされたネットワークがNEXT_HOP属性のスピーカーに到達できる内部ピアルーター（または内部ルーター）のインターフェイスアドレスを使用できます。ピアXがこのアドレスと共通のサブネットを共有している場合。これは、「サードパーティ」のNEXT_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.
- それ以外の場合、アナウンスされるルートが外部ピアから学習された場合、スピーカーは、そのピアが提供する場合、スピーカー自体がNEXT_HOP属性でローカルルート計算に使用する隣接ルーターのIPアドレス（受信したNEXT_HOP属性から既知）を使用できますXはこのアドレスと共通のサブネットを共有します。これは、「サードパーティ」のNEXT_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つと共通のサブネットを共有している場合、スピーカーは、そのようなインターフェイスに関連付けられているIPアドレスをNEXT_HOP属性で使用できます。これは「ファーストパーティ」のNEXT_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スピーカーは、スピーカーがピアXへのBGP接続を確立するために使用するインターフェースのIPアドレスをNEXT_HOP属性で使用する必要があります（SHOULD）。
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 attribute of the learned route (the speaker does not modify the NEXT_HOP attribute).
- スピーカーは、NEXT_HOP属性を伝播するように構成できます（MAY）。この場合、スピーカーがピアの1つから学習したルートをアドバタイズする場合、アドバタイズされたルートのNEXT_HOP属性は、学習したルートのNEXT_HOP属性とまったく同じです（スピーカーはNEXT_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スピーカーは、スピーカーがNEXT_HOP属性で使用するインターフェースのIPアドレスを使用して、ピアXへのBGP接続を確立する必要があります（SHOULD）。
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.
通常、NEXT_HOP属性は、利用可能な最短のパスが使用されるように選択されます。 BGPスピーカーは、不完全にブリッジされたメディアを処理するために、サードパーティのNEXT_HOP属性の無効化通知をサポートできなければなりません（MUST）。
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スピーカーから発信されたルートは、そのピアのアドレスをNEXT_HOPとして使用して、そのピアにアドバタイズされるべきではない（SHALL）。 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.
BGPスピーカーはNEXT_HOP属性を使用して、中継パケットを関連する宛先に転送するために使用する必要がある実際のアウトバウンドインターフェイスと即時ネクストホップアドレスを決定します。
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.
即時ネクストホップアドレスは、ルーティングテーブルの内容を使用して、NEXT_HOP属性のIPアドレスに対して再帰的なルートルックアップ操作を実行し、等しいコストのエントリが複数存在する場合に1つのエントリを選択することによって決定されます。 NEXT_HOP属性のIPアドレスを解決するルーティングテーブルエントリは、常に送信インターフェイスを指定します。エントリが接続されたサブネットを指定しているが、ネクストホップアドレスを指定していない場合は、NEXT_HOP属性のアドレスを直接のネクストホップアドレスとして使用する必要があります（SHOULD）。エントリがネクストホップアドレスも指定している場合、このアドレスは、パケット転送の直接のネクストホップアドレスとして使用する必要があります（SHOULD）。
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属性の値は、メトリックと呼ばれる4オクテットの符号なし数値です。他のすべての要素が等しい場合は、メトリックが低い出口ポイントを優先する必要があります。 EBGPを介して受信した場合、MULTI_EXIT_DISC属性は、IBGPを介して同じAS内の他のBGPスピーカーに伝播される場合があります（9.1.2.2も参照）。隣接ASから受信したMULTI_EXIT_DISC属性は、他の隣接ASに伝播してはならない（MUST NOT）。
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 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).
BGPスピーカーは、MULTI_EXIT_DISC属性をルートから削除できるようにするメカニズム（ローカル構成に基づく）を実装する必要があります。 BGPスピーカーがMULTI_EXIT_DISC属性をルートから削除するように構成されている場合、この削除は、ルートの優先度を決定する前、およびルート選択を実行する前に行う必要があります（決定プロセスフェーズ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属性の値を（ローカル構成に基づいて）変更することもできます（MAY）。 BGPスピーカーがEBGPで受信したMULTI_EXIT_DISC属性の値を変更するように構成されている場合、値の変更は、ルートの優先度を決定する前、およびルート選択を実行する前に行う必要があります（決定プロセスフェーズ1および2）。これに必要な制限については、9.1.2.2項を参照してください。
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は、特定のBGPスピーカーが他の内部ピアに送信するすべてのUPDATEメッセージに含まれる必要があるよく知られた属性です。 BGPスピーカーは、ローカルに構成されたポリシーに基づいて各外部ルートの優先度を計算し、内部ピアにルートをアドバタイズするときに優先度を含める必要があります（SHALL）。より高い優先度を優先する必要があります。 BGPスピーカーは、決定プロセスで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スピーカーは、BGPコンフェデレーション[RFC3065]の場合を除いて、外部ピアに送信するUPDATEメッセージにこの属性を含めてはなりません（MUST NOT）。外部ピアから受信したUPDATEメッセージに含まれている場合、BGPコンフェデレーション[RFC3065]の場合を除いて、この属性は受信スピーカーによって無視される必要があります。
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には、通常、集約が形成されたASのセットから形成された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番号の少なくとも一部が集約によって除外される場合、集約されたルートは、ピアにアドバタイズされるときに、ATOMIC_AGGREGATE属性を含める必要があります（SHOULD）。
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属性を持つルートを受信するBGPスピーカーは、他のスピーカーにルートを伝播するときに属性を削除してはなりません（SHOULD NOT）。
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スピーカーは、このルートを他のBGPスピーカーにアドバタイズするときに、そのルートのNLRIを（9.1.4で定義されているように）より具体的にすることはできません。
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属性。
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.
AGGREGATORはオプションの推移的な属性であり、集約によって形成される更新に含まれる場合があります（セクション9.2.2.2を参照）。ルート集約を実行するBGPスピーカーは、独自のAS番号とIPアドレスを含む必要があるAGGREGATOR属性を追加する場合があります。 IPアドレスは、スピーカーのBGP IDと同じである必要があります。
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.
ここで説明する条件のいずれかが検出されると、示されたエラーコード、エラーサブコード、およびデータフィールドを含むNOTIFICATIONメッセージが送信され、BGP接続が閉じられます（NOTIFICATIONメッセージが送信されないことが明示的に記述されている場合を除く） BGP接続は閉じられません）。エラーサブコードが指定されていない場合は、ゼロを使用する必要があります。
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-Inがクリアされ、そのBGP接続のすべてのリソースが割り当て解除されたことを意味します。リモートピアに関連付けられているLoc-RIBのエントリは無効としてマークされます。ローカルシステムは、無効とマークされたルートの宛先の最適ルートを再計算します。無効なルートがシステムから削除される前に、無効とマークされたルート、またはシステムから無効なルートが削除される前の新しい最適ルートのいずれかを撤回して、ピアにアドバタイズします。
Unless specified explicitly, the Data field of the NOTIFICATION message that is sent to indicate an error is empty.
明示的に指定されていない限り、エラーを示すために送信されるNOTIFICATIONメッセージのDataフィールドは空です。
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.
メッセージヘッダーの処理中に検出されたすべてのエラーは、エラーコードメッセージヘッダーエラーと共にNOTIFICATIONメッセージを送信することによって示される必要があります。エラーサブコードは、エラーの特定の性質を詳しく説明します。
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フィールドの期待値はすべて1です。メッセージヘッダーのマーカーフィールドが期待どおりでない場合は、同期エラーが発生しているため、エラーサブコードを[同期しない接続]に設定する必要があります。
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
- メッセージヘッダーの長さフィールドが19未満または4096より大きい場合、または
- if the Length field of an OPEN message is less than the minimum length of the OPEN message, or
- OPENメッセージの長さフィールドがOPENメッセージの最小長より短い場合、または
- 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メッセージの長さフィールドが19でない場合、または
- if the Length field of a NOTIFICATION message is less than the minimum length of the NOTIFICATION message,
- NOTIFICATIONメッセージの長さフィールドがNOTIFICATIONメッセージの最小長より短い場合、
then the Error Subcode MUST be set to Bad Message Length. The Data field MUST contain the erroneous Length field.
次に、エラーサブコードを不正なメッセージ長に設定する必要があります。データフィールドには、誤った長さフィールドが含まれている必要があります。
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に設定する必要があります。データフィールドには、誤ったタイプフィールドが含まれている必要があります。
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.
OPENメッセージの処理中に検出されたすべてのエラーは、エラーメッセージOPENメッセージエラーとともにNOTIFICATIONメッセージを送信することによって示される必要があります。エラーサブコードは、エラーの特定の性質を詳しく説明します。
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 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.
受信したOPENメッセージのVersionフィールドのバージョン番号がサポートされていない場合、Error SubcodeをUnsupported Version Numberに設定する必要があります。データフィールドは2オクテットの符号なし整数であり、ローカルでサポートされる最大のバージョン番号が、リモートのBGPピアの入札（受信したOPENメッセージで示される）バージョンよりも小さいか、ローカルでサポートされる最小のバージョン番号であるかを示します。リモート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.
OPENメッセージの自律システムフィールドが受け入れられない場合、エラーサブコードをBad Peer ASに設定する必要があります。受け入れ可能な自律システム番号の決定は、このプロトコルの範囲外です。
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.
OPENメッセージのHold Timeフィールドが受け入れられない場合は、Error SubcodeをUnacceptable Hold Timeに設定する必要があります。実装では、1秒または2秒のホールドタイム値を拒否する必要があります。実装は、提案された保持時間を拒否してもよい（MAY）。保持時間を受け入れる実装は、保持時間のネゴシエートされた値を使用する必要があります。
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.
OPENメッセージのBGP IDフィールドが構文的に正しくない場合は、エラーサブコードをBad BGP Identifierに設定する必要があります。構文の正確さは、BGP IDフィールドが有効なユニキャスト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.
OPENメッセージのオプションパラメータの1つが認識されない場合、エラーサブコードをサポートされないオプションパラメータに設定する必要があります。
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).
OPENメッセージのオプションパラメータの1つが認識されても、形式が正しくない場合は、エラーサブコードを0（不特定）に設定する必要があります。
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.
UPDATEメッセージの処理中に検出されたすべてのエラーは、エラーメッセージUPDATEメッセージエラーとともにNOTIFICATIONメッセージを送信することによって示される必要があります。エラーサブコードは、エラーの特定の性質を詳しく説明します。
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メッセージのエラーチェックは、パス属性を調べることから始まります。撤回されたルートの長さまたは属性の長さの合計が大きすぎる場合（つまり、撤回されたルートの長さ+属性の合計の長さ+ 23がメッセージの長さを超える場合）、エラーサブコードは不正な属性リストに設定する必要があります。
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).
認識された属性に、属性タイプコードと競合する属性フラグがある場合、エラーサブコードを属性フラグエラーに設定する必要があります。データフィールドには、誤った属性（タイプ、長さ、および値）が含まれている必要があります。
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).
認識された属性に（属性タイプコードに基づいて）予想される長さと競合する属性長がある場合、エラーサブコードは属性長エラーに設定する必要があります。データフィールドには、誤った属性（タイプ、長さ、および値）が含まれている必要があります。
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.
既知の必須属性のいずれかが存在しない場合、エラーサブコードを不明な既知の属性に設定する必要があります。データフィールドには、欠落している既知の属性の属性タイプコードを含める必要があります。
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).
既知の必須属性のいずれかが認識されない場合は、エラーサブコードを認識されない既知の属性に設定する必要があります。データフィールドには、認識されない属性（タイプ、長さ、および値）が含まれている必要があります。
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属性に未定義の値がある場合、エラーサブコードは無効な生成元属性に設定する必要があります。データフィールドには、認識されない属性（タイプ、長さ、および値）が含まれている必要があります。
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.
NEXT_HOP属性フィールドが構文的に正しくない場合は、エラーサブコードを無効なNEXT_HOP属性に設定する必要があります。データフィールドには、不正な属性（タイプ、長さ、値）が含まれている必要があります。構文の正確さは、NEXT_HOP属性が有効なIPホストアドレスを表すことを意味します。
The IP address in the NEXT_HOP MUST meet the following criteria to be considered semantically correct:
NEXT_HOPの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の場合、送信側と受信側は互いに1ホップのIPホップであり、NEXT_HOPのIPアドレスは、BGP接続を確立するために使用される送信側のIPアドレスか、NEXT_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.
NEXT_HOP属性が意味的に正しくない場合、エラーがログに記録されるべきであり（SHOULD）、ルートは無視されるべきです（SHOULD）。この場合、NOTIFICATIONメッセージは送信されるべきではなく（SHOULD NOT）、接続は閉じられるべきではありません（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属性の構文が正しいかどうかがチェックされます。パスが構文的に正しくない場合は、エラーサブコードを不正なAS_PATHに設定する必要があります。
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が、ピアを送信したピアの自律システム番号と等しいかどうかを確認できます（MAY）。メッセージ。チェックがそうでないと判断した場合は、エラーサブコードを不正な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).
オプションの属性が認識される場合は、この属性の値を確認する必要があります。エラーが検出された場合は、属性を破棄する必要があり、エラーサブコードはオプションの属性エラーに設定する必要があります。データフィールドには、属性（タイプ、長さ、および値）を含める必要があります。
If any attribute appears more than once in the UPDATE message, then the Error Subcode MUST be set to Malformed Attribute List.
属性がUPDATEメッセージに複数回出現する場合は、エラーサブコードを不正な属性リストに設定する必要があります。
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フィールドは、構文の妥当性がチェックされます。フィールドが構文的に正しくない場合は、エラーサブコードを無効なネットワークフィールドに設定する必要があります。
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.
NLRIフィールドのプレフィックスが意味的に正しくない場合（予期しないマルチキャストIPアドレスなど）、ローカルでエラーをログに記録する必要があり（SHOULD）、プレフィックスを無視する必要があります（SHOULD）。
An UPDATE message that contains correct path attributes, but no NLRI, SHALL be treated as a valid UPDATE message.
正しいパス属性を含むがNLRIを含まないUPDATEメッセージは、有効なUPDATEメッセージとして扱われる必要があります（SHALL）。
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メッセージを使用してこのエラーをピアに報告できません。そのようなエラー（たとえば、認識されないエラーコードまたはエラーサブコード）は、通知され、ローカルでログに記録され、ピアの管理者に通知される必要があります。ただし、これを行う方法は、このドキュメントの範囲外です。
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.
システムがOPENメッセージのHold Timeフィールドで指定された期間内に連続するKEEPALIVE、UPDATE、またはNOTIFICATIONメッセージを受信しない場合、Hold Timer Expired Error Codeを含むNOTIFICATIONメッセージが送信され、BGP接続が閉じられます。
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有限状態マシンによって検出されたエラー（予期しないイベントの受信など）は、エラーコード有限状態マシンエラーを含むNOTIFICATIONメッセージを送信することによって示されます。
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ピアは、いつでも、エラーコードの停止を伴うNOTIFICATIONメッセージを送信してBGP接続を閉じることを選択できます（MAY）。ただし、このセクションで示されている致命的なエラーが存在する場合は、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）ネイバーからの新しいアドレスプレフィックスを破棄します（ネイバーとのBGP接続を維持しながら）、または（b）ネイバーとのBGP接続を終了します。ネイバーから受信したアドレスプレフィックスの数がローカルに設定された上限を超えているため、BGPスピーカーがネイバーとのBGP接続を終了することを決定した場合、スピーカーはエラーコードが停止した通知メッセージをネイバーに送信する必要があります。スピーカーはこれをローカルに記録してもよい（MAY）。
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つの並列接続が適切に形成されます。これらの接続の1つで使用されるソースIPアドレスが、他の接続で使用される宛先IPアドレスと同じで、最初の接続で使用される宛先IPアドレスが、他の接続で使用されるソースIPアドレスと同じである場合、接続の衝突発生した。接続の衝突が発生した場合、接続の1つを閉じる必要があります。
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 IDの値に基づいて、衝突が発生したときにどのBGP接続を保持するかを検出するための規則が確立されます。規約は、衝突に関与するピアのBGP識別子を比較し、より高い値のBGP識別子を持つBGPスピーカーによって開始された接続のみを保持することです。
Upon receipt of an OPEN message, the local system MUST examine all of its connections that are in the OpenConfirm state. A BGP speaker MAY also examine connections in an OpenSent state if it knows the BGP Identifier of the peer by means outside of the protocol. If, among these connections, there is a connection to a remote BGP speaker whose BGP Identifier equals the one in the OPEN message, and this connection collides with the connection over which the OPEN message is received, then the local system performs the following collision resolution procedure:
ローカルシステムは、OPENメッセージを受信すると、OpenConfirm状態にあるすべての接続を検査する必要があります。 BGPスピーカーは、プロトコル外の方法でピアのBGP IDを知っている場合、OpenSent状態の接続も検査できます（MAY）。これらの接続の中で、BGP IDがOPENメッセージのIDと等しいリモートBGPスピーカーへの接続があり、この接続がOPENメッセージを受信した接続と衝突する場合、ローカルシステムは次の衝突解決を実行します。手順：
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 IDがリモートシステムのBGP IDと比較されます（OPENメッセージで指定されているとおり）。 BGP識別子の比較は、それらをホストバイトオーダーに変換し、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識別子の値がリモートの値より小さい場合、ローカルシステムは既存の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接続（新しく受信したOPENメッセージに関連付けられたもの）を閉じ、既存の接続（すでに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.
構成を介して許可されない限り、確立済み状態にある既存のBGP接続との接続の衝突により、新しく作成された接続が閉じられます。
Note that a connection collision cannot be detected with connections that are in Idle, Connect, or Active states.
接続の衝突は、アイドル、接続、またはアクティブ状態の接続では検出できないことに注意してください。
Closing the BGP connection (that results from the collision resolution procedure) is accomplished by sending the NOTIFICATION message with the Error Code Cease.
（衝突解決手順の結果として）BGP接続を閉じるには、エラーコードの停止とともにNOTIFICATIONメッセージを送信します。
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接続を開くことを複数回試行することにより、プロトコルのバージョンをネゴシエートできます（MAY）。エラーコード、OPENメッセージエラー、エラーサブコード、サポートされていないバージョン番号でオープン試行が失敗した場合、BGPスピーカーは、試したバージョン番号、ピアが試したバージョン番号、ピアから渡されたバージョン番号を利用できます。 NOTIFICATIONメッセージ、およびそれがサポートするバージョン番号。 2つのピアが1つ以上の共通バージョンをサポートしている場合、これにより、それらは最も高い共通バージョンを迅速に決定できます。 BGPバージョンネゴシエーションをサポートするために、BGPの将来のバージョンでは、OPENおよびNOTIFICATIONメッセージのフォーマットを保持する必要があります。
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:
このセクションでは、有限状態マシン（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）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）ConnectRetryCounter 3）ConnectRetryTimer 4）ConnectRetryTime 5）HoldTimer 6）HoldTime 7）KeepaliveTimer 8）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:
オプションのセッション属性を以下に示します。これらのオプション属性は、接続ごとまたはローカルシステムごとにサポートされます。
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）AcceptConnectionsUnconfiguredPeers 2）AllowAutomaticStart 3）AllowAutomaticStop 4）CollisionDetectEstablishedState 5）DampPeerOscillations 6）DelayOpen 7）DelayOpenTime 8）DelayOpenTimer 9）IdleHoldTime 10）IdleHoldTimer 11）PassiveTcpEstablishment 12）SendNOTIFICATIONOPENOPEN13）TrackTcpState
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関数がアクティブであることを示すオプションの属性です。 「Time」値は、「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節では、さまざまなタイプのオプション属性（フラグまたはタイマー）の概要も示します。
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への入力はイベントです。イベントは必須またはオプションです。一部のオプションのイベントは、オプションのセッション属性にリンクされています。オプションのセッション属性により、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に発行が開始されることを意味します。
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ピアが次の自動再起動を許可する前にアイドル状態で保持される時間の長さを指定します。 IdleHoldTimerは、ピアをアイドル状態に保持するタイマーです。
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.
DampPeerOscillationsロジックの例は、BGPピアが一定の時間内に接続（接続/切断）を繰り返し発振する場合のIdleHoldTime値の増加です。このロジックを実行するために、ピアは5分以内に10回接続および切断できます。 IdleHoldTime値は0から120秒にリセットされます。
Values: TRUE or FALSE
値：TRUEまたは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
値：TRUEまたは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接続がアイドル状態のBGPピアの発振を減衰するロジックを使用していることを示します。
Value: TRUE or FALSE
値：TRUEまたは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は、特定の期間、BGPピアをアイドル状態に保つために使用されます。 IdleHoldTimer_Expiresイベントについては、セクション8.1.3で説明します。
Values: Time in seconds
値：秒単位の時間
Group 2: Unconfigured Peers
グループ2：未構成のピア
Optional Session Attributes: AcceptConnectionsUnconfiguredPeers
Option 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脆弱性ドキュメント[RFC4272]を参照してください。
Value: True or False
値：TrueまたはFalse
Group 3: TCP processing
グループ3：TCP処理
Optional Session Attributes: PassiveTcpEstablishment, TrackTcpState
オプションのセッション属性：PassiveTcpEstablishment、TrackTcpState
Option 1: PassiveTcpEstablishment Description: This option indicates that the BGP FSM will passively wait for the remote BGP peer to establish the BGP TCP connection.
オプション1：PassiveTcpEstablishment説明：このオプションは、BGP FSMがリモートBGPピアがBGP TCP接続を確立するまで受動的に待機することを示します。
value: TRUE or FALSE
値：TRUEまたは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
値：TRUEまたは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）のOPENメッセージの送信を遅延するように実装を構成できます。遅延により、リモートBGPピアは最初のOPENメッセージを送信できます。
Value: TRUE or FALSE
値：TRUEまたは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 connection. The DelayOpenTimer_Expires event (Event 12) is described in Section 8.1.3.
説明：DelayOpenTimerオプションのセッション属性は、接続でのOPENメッセージの送信を遅らせるために使用されます。 DelayOpenTimer_Expiresイベント（イベント12）については、セクション8.1.3で説明します。
Value: Time in seconds
値：秒単位の時間
Option 4: SendNOTIFICATIONwithoutOPEN
オプション4：OPENなしのSendNOTIFICATION
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を使用すると、ピアは最初にOPENメッセージを送信せずにNOTIFICATIONを送信できます。このオプションのセッション属性がない場合、BGP接続は、ピアがNOTIFICATIONメッセージを送信する前に、OPENメッセージをピアが送信する必要があると想定します。
Value: True or False
値：Trueまたは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.
説明：通常、衝突の検出（セクション6.8を参照）は、確立状態では無視されます。このオプションのセッション属性は、このBGP接続が確立済み状態の衝突を処理することを示します。
Value: True or False
値：Trueまたは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 MIB（バージョン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ポリシーエンジンがBGP有限状態マシンに信号を送り、BGP状態マシンを開始または停止するイベントです。基本的な開始および停止の指示は、特定のタイプの開始または停止メカニズムをBGP FSMに通知するオプションの接続属性によって拡張されます。この組み合わせの例は、イベント5、AutomaticStart_with_PassiveTcpEstablishmentです。このイベントにより、BGP実装は、パッシブTCP確立を使用するオプション付きの自動開始を使用していることをBGP FSMに通知します。パッシブTCP確立は、このBGP FSMがリモート側がTCP確立を開始するのを待つことを通知します。
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.
イベント1（ManualStart）とイベント2（ManualStop）のみが必須の管理イベントであることに注意してください。他のすべての管理イベントはオプションです（イベント3〜8）。以下の各イベントには、名前、定義、ステータス（必須またはオプション）、および各ステージで設定する必要があるオプションのセッション属性があります。 BGP FSMのイベント1からイベント8を生成するとき、「オプションの属性ステータス」セクションで指定された条件が検証されます。これらの条件のいずれかが満たされない場合、ローカルシステムは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属性を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 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属性をTRUEに設定する必要があります。 2）PassiveTcpEstablishmentオプションのセッション属性がサポートされている場合は、FALSEに設定する必要があります。 3）DampPeerOscillationsがサポートされている場合、このイベントの発生時にFALSEに設定する必要があります（SHOULD）。
Event 4: ManualStart_with_PassiveTcpEstablishment
イベント4：ManualStart_with_PassiveTcpEstablishment
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属性をTRUEに設定する必要があります。 2）このイベントが発生した場合、DampPeerOscillations属性をFALSEに設定する必要があります。
Event 5: AutomaticStart_with_PassiveTcpEstablishment
イベント5：AutomaticStart_with_PassiveTcpEstablishment
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属性をTRUEに設定する必要があります。 2）PassiveTcpEstablishment属性をTRUEに設定する必要があります。 3）DampPeerOscillations属性がサポートされている場合、DampPeerOscillationsをFALSEに設定する必要があります（SHOULD）。
Event 6: AutomaticStart_with_DampPeerOscillations
イベント6：AutomaticStart_with_DampPeerOscillations
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属性をTRUEに設定する必要があります。 2）DampPeerOscillations属性はTRUEに設定する必要があります。 3）PassiveTcpEstablishment属性をFALSEに設定する必要があります。
Event 7: AutomaticStart_with_DampPeerOscillations_and_ PassiveTcpEstablishment
イベント7：AutomaticStart_with_DampPeerOscillations_and_ PassiveTcpEstablishment
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属性をTRUEに設定する必要があります。 2）DampPeerOscillations属性はTRUEに設定する必要があります。 3）PassiveTcpEstablishment属性を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.
自動停止イベントの例としては、特定のピアのプレフィックス数を超え、ローカルシステムがピアを自動的に切断することがあります。
Status: Optional, depending on local system
ステータス：オプション、ローカルシステムに依存
Optional Attribute Status: 1) The AllowAutomaticStop attribute SHOULD be TRUE.
オプションの属性ステータス：1）AllowAutomaticStop属性はTRUEである必要があります。
Event 9: ConnectRetryTimer_Expires
イベント9：ConnectRetryTimer_Expires
Definition: An event generated when the ConnectRetryTimer expires.
定義：ConnectRetryTimerの有効期限が切れたときに生成されるイベント。
Status: Mandatory
ステータス：必須
Event 10: HoldTimer_Expires
イベント10：HoldTimer_Expires
Definition: An event generated when the HoldTimer expires.
定義：HoldTimerが期限切れになったときに生成されるイベント。
Status: Mandatory
ステータス：必須
Event 11: KeepaliveTimer_Expires
イベント11：KeepaliveTimer_Expires
Definition: An event generated when the KeepaliveTimer expires.
定義：KeepaliveTimerが期限切れになるときに生成されるイベント。
Status: Mandatory
ステータス：必須
Event 12: DelayOpenTimer_Expires
イベント12：DelayOpenTimer_Expires
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属性をTRUEに設定する必要があります（SHOULD）、2）DelayOpenTime属性をサポートする必要があります（SHOULD）、3）DelayOpenTimerをサポートする必要があります（SHOULD）。
Event 13: IdleHoldTimer_Expires
イベント13：IdleHoldTimer_Expires
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ピアの発振を防止したことを示します。
The IdleHoldTimer is only used when the persistent peer oscillation damping function is enabled by setting the DampPeerOscillations optional attribute to TRUE.
IdleHoldTimerは、DampPeerOscillationsオプション属性をTRUEに設定して永続的なピア振動減衰機能を有効にした場合にのみ使用されます。
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属性をTRUEに設定する必要があります。 2）IdleHoldTimerは期限切れになったばかりです。
Event 14: TcpConnection_Valid
イベント14：TcpConnection_Valid
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ポート、宛先IPアドレス、およびTCPポートを持つTCP接続要求のローカルシステム受信を示すイベント。無効な送信元および無効な宛先IPアドレスの定義は、実装によって決定されます。
BGP's destination port SHOULD be port 179, as defined by IANA.
BGPの宛先ポートは、IANAで定義されているように、ポート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属性をTRUEに設定する必要があります。
Event 15: Tcp_CR_Invalid
イベント15：Tcp_CR_Invalid
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接続要求のローカルシステム受信を示すイベント。
BGP destination port number SHOULD be 179, as defined by IANA.
BGP宛先ポート番号は、IANAで定義されているように、179にする必要があります（SHOULD）。
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
ステータス：必須
Event 19: BGPOpen
イベント19：BGPOpen
Definition: An event is generated when a valid OPEN message has been received.
定義：有効なOPENメッセージが受信されると、イベントが生成されます。
Status: Mandatory
ステータス：必須
Optional Attribute Status: 1) The DelayOpen optional attribute SHOULD be set to FALSE. 2) The DelayOpenTimer SHOULD not be running.
オプション属性のステータス：1）DelayOpenオプション属性はFALSEに設定する必要があります。 2）DelayOpenTimerが実行されていない必要があります。
Event 20: BGPOpen with DelayOpenTimer running
イベント20：BGPOpenとDelayOpenTimerの実行
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オープンメッセージの送信を遅らせているピアに対して有効なOPENメッセージが受信されると、イベントが生成されます。
Status: Optional
ステータス：オプション
Optional Attribute Status: 1) The DelayOpen attribute SHOULD be set to TRUE. 2) The DelayOpenTimer SHOULD be running.
オプションの属性ステータス：1）DelayOpen属性はTRUEに設定する必要があります。 2）DelayOpenTimerが実行されている必要があります。
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.
定義：OPENメッセージがエラーとともに受信された場合、イベントが生成されます。
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 connection has been selected to be disconnected. See Section 6.8 for more information on collision detection.
定義：着信OPENメッセージの処理中に接続の衝突が検出され、この接続が切断されるように選択された場合に、管理上生成されるイベント。衝突検出の詳細については、セクション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.
オプションの属性ステータス：状態マシンが確立済み状態でこのイベントを処理する場合、1）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
ステータス：必須
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
ステータス：必須
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は、設定されたピアごとに個別のFSMを維持する必要があります。潜在的な接続でペアになっている各BGPピアは、アイドル状態を維持するように構成されているか、パッシブを維持するように構成されていない限り、もう一方への接続を試みます。この説明では、TCP接続のアクティブ側または接続側（最初のTCP SYNパケットを送信するTCP接続の側）を発信と呼びます。パッシブまたはリスニング側（最初のSYN / ACKの送信側）は、着信接続と呼ばれます。 （以下で使用されるアクティブおよびパッシブの用語については、セクション8.2.1.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実装は、ピアへの接続の試行に加えて、着信接続をTCPポート179に接続してリッスンする必要があります。着信接続ごとに、状態マシンをインスタンス化する必要があります。着信接続の相手側のピアのIDはわかっているが、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実装では、構成されたピアリングごとに最大で1つのFSMと、ピアがまだ識別されていない着信TCP接続ごとに1つのFSMがあります。各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アドレスのペアを使用するように構成されている場合、ピアのペア間に複数の接続が存在する可能性があります。これは、同じピアに対する複数の「構成済みピアリング」と呼ばれます。
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接続またはピアに適用される場合、アクティブとパッシブという言葉の意味は少し異なります。上記の定義および以下の状態マシンごとに、1つのTCP接続に対してアクティブな側とパッシブな側が1つずつあります。 BGPスピーカーがアクティブとして構成されている場合、最終的に確立される接続のアクティブ側またはパッシブ側のいずれかで終了する可能性があります。 TCP接続が完了すると、どちらがアクティブでどちらがパッシブであったかは関係ありません。唯一の違いは、TCP接続のどちら側にポート番号179があるかです。
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接続ごとに1つのFSMがあります。接続が関連付けられているピアを決定する前に接続の衝突が発生すると、1つのピアに2つの接続が存在する可能性があります。接続の衝突が解決された後（セクション6.8を参照）、閉じられた接続のFSMを破棄する必要があります（SHOULD）。
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.
オプションのセッション属性は、フラグ（TRUEまたはFALSE）またはオプションのタイマーとして機能する属性を指定します。フラグとして機能するオプション属性の場合、オプションのセッション属性をシステムでTRUEに設定できる場合、対応するBGP FSMアクションをサポートする必要があります。たとえば、BGP実装でAutoStartおよびPassiveTcpEstablishmentオプションを設定できる場合、イベント3、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.
- サポートを示すフラグ、-タイマーで設定された時間-タイマー。
The two optional timers show this format:
2つのオプションのタイマーはこの形式を示します。
DelayOpenTimer: DelayOpen, DelayOpenTime, DelayOpenTimer IdleHoldTimer: DampPeerOscillations, IdleHoldTime, IdleHoldTimer
DelayOpenTimer：DelayOpen、DelayOpenTime、DelayOpenTimer IdleHoldTimer：DampPeerOscillations、IdleHoldTime、IdleHoldTimer
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に設定できない場合、そのオプションをサポートするタイマーとイベントをサポートする必要はありません。
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.
このステートマシンの説明で使用されるイベント番号（1〜28）は、BGPステートマシンの動作を指定するのに役立ちます。実装はこれらの番号を使用してネットワーク管理情報を提供することができます。 FSMまたはFSMイベントの正確な形式は、各実装に固有です。
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ドキュメントの範囲外です。
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はアイドル状態です。以降、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.
- 状態を接続に変更します。
The ManualStop event (Event 2) and AutomaticStop (Event 8) event are ignored in the Idle state.
ManualStopイベント（イベント2）およびAutomaticStop（イベント8）イベントは、アイドル状態では無視されます。
In response to a ManualStart_with_PassiveTcpEstablishment event (Event 4) or AutomaticStart_with_PassiveTcpEstablishment event (Event 5), the local system:
ManualStart_with_PassiveTcpEstablishmentイベント（イベント4）またはAutomaticStart_with_PassiveTcpEstablishmentイベント（イベント5）に応答して、ローカルシステムは次のことを行います。
- 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.
- 状態をアクティブに変更します。
The exact value of the ConnectRetryTimer is a local matter, but it SHOULD be sufficiently large to allow TCP initialization.
ConnectRetryTimerの正確な値はローカルな問題ですが、TCPの初期化を可能にするのに十分な大きさである必要があります。
If the DampPeerOscillations attribute is set to TRUE, the following three additional events may occur within the Idle state:
DampPeerOscillations属性がTRUEに設定されている場合、アイドル状態内で次の3つの追加イベントが発生する可能性があります。
- AutomaticStart_with_DampPeerOscillations (Event 6),
- AutomaticStart_with_DampPeerOscillations（Event 6）、
- AutomaticStart_with_DampPeerOscillations_and_ PassiveTcpEstablishment (Event 7),
- AutomaticStart_with_DampPeerOscillations_and_ PassiveTcpEstablishment（Event 7）、
- IdleHoldTimer_Expires (Event 13).
- IdleHoldTimer_Expires（イベント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状態で受信したその他のイベント（イベント9〜12、15〜28）は、ローカルシステムの状態を変更しません。
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.
接続状態では、開始イベント（イベント1、3〜7）は無視されます。
In response to a ManualStop event (Event 2), the local system:
ManualStopイベント（イベント2）に応答して、ローカルシステムは次のことを行います。
- drops the TCP connection,
- TCP接続をドロップし、
- releases all BGP resources,
- すべてのBGPリソースを解放し、
- sets ConnectRetryCounter to zero,
- ConnectRetryCounterをゼロに設定し、
- stops the ConnectRetryTimer and sets ConnectRetryTimer to zero, and
- ConnectRetryTimerを停止し、ConnectRetryTimerをゼロに設定します。
- changes its state to 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.
- 接続状態のままです。
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,
- OPENメッセージをピアに送信し、
- 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接続が処理され、接続は接続状態のままになります。
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接続を拒否し、接続は接続状態のままになります。
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またはイベント17）、ローカルシステムは処理の前に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を初期値に設定し、
- stays in the Connect state.
- 接続状態のままです。
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,
- OPENメッセージをピアに送信し、
- sets the HoldTimer to a large value, and
- sets the HoldTimer to a large value, and
- 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.
- 状態をアクティブに変更します。
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.
- 状態をアイドルに変更します。
If an OPEN message is received while the DelayOpenTimer is running (Event 20), the local system:
DelayOpenTimerの実行中にOPENメッセージを受信した場合（イベント20）、ローカルシステムは次のことを行います。
- stops the ConnectRetryTimer (if running) and sets the ConnectRetryTimer to zero,
- ConnectRetryTimerを停止し（実行中の場合）、ConnectRetryTimerをゼロに設定します。
- completes the BGP initialization,
- BGPの初期化を完了します。
- stops and clears the DelayOpenTimer (sets the value to zero),
- DelayOpenTimerを停止してクリアします（値をゼロに設定します）。
- sends an OPEN message,
- OPENメッセージを送信し、
- 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".
自律システムフィールドの値がローカルの自律システム番号と同じ場合は、接続ステータスを内部接続に設定します。それ以外の場合は「外部」になります。
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）またはOPENメッセージチェックでエラー（イベント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,
- stops the ConnectRetryTimer (if running) and sets the ConnectRetryTimer to zero,
- 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.
- changes its state to 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:
NOTIFICATIONメッセージがバージョンエラー（イベント24）で受信された場合、ローカルシステムは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,
- releases all BGP resources,
- drops the TCP connection, and
- TCP接続をドロップし、
- changes its state to Idle.
- changes its state to 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.
- 状態をアイドルに変更します。
In response to any other events (Events 8, 10-11, 13, 19, 23, 25-28), the local system:
その他のイベント（イベント8、10〜11、13、19、23、25〜28）に応答して、ローカルシステムは次のことを行います。
- 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.
- 状態をアイドルに変更します。
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.
開始イベント（イベント1、3〜7）は、アクティブ状態では無視されます。
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セッション属性が設定されている場合、ローカルシステムは、Casease付きのNOTIFICATIONを送信します。
- 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.
- 状態をアイドルに変更します。
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.
- 状態を接続に変更します。
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,
- OPENメッセージをリモートピアに送信します。
- 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接続フラグを処理し、アクティブ状態のままになります。
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接続を拒否し、アクティブ状態のままです。
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またはイベント17）に応じて、ローカルシステムは処理の前に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
- DelayOpenTimerを初期値（DelayOpenTime）に設定し、
- stays in the Active state.
- アクティブ状態のままです。
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,
- OPENメッセージをピアに送信し、
- 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.
HoldTimerの「大きな値」として、4分のHoldTimer値が推奨されます。
If the local system receives a TcpConnectionFails event (Event 18), the local system:
ローカルシステムがTcpConnectionFailsイベント（イベント18）を受信した場合、ローカルシステムは次のことを行います。
- restarts the ConnectRetryTimer (with the initial value),
- ConnectRetryTimerを再起動します（初期値を使用）。
- 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.
- 状態をアイドルに変更します。
If an OPEN message is received and the DelayOpenTimer is running (Event 20), the local system:
OPENメッセージが受信され、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,
- OPENメッセージを送信し、
- 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.
自律システムフィールドの値がローカルの自律システム番号と同じ場合は、接続ステータスを内部接続に設定します。それ以外の場合は外部になります。
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）またはOPENメッセージチェックでエラー（イベント22）が検出された場合（セクション6.2を参照）、ローカルシステムは次のことを行います。
- (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.
- 状態をアイドルに変更します。
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:
NOTIFICATIONメッセージがバージョンエラー（イベント24）で受信された場合、ローカルシステムは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.
- 状態をアイドルに変更します。
If the DelayOpenTimer is not running, the local system:
DelayOpenTimerが実行されていない場合、ローカルシステム：
- sets the ConnectRetryTimer to zero,
- ConnectRetryTimerをゼロに設定し、
- releases all BGP resources,
- releases all BGP resources,
- 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.
- 状態をアイドルに変更します。
In response to any other event (Events 8, 10-11, 13, 19, 23, 25-28), the local system:
その他のイベント（イベント8、10〜11、13、19、23、25〜28）に応答して、ローカルシステムは次のことを行います。
- 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.
- 状態をアイドルに変更します。
OpenSent:
OpenSent：
In this state, BGP FSM waits for an OPEN message from its peer.
In this state, BGP FSM waits for an OPEN message from its peer.
The start events (Events 1, 3-7) are ignored in the OpenSent state.
The start events (Events 1, 3-7) are ignored in the OpenSent state.
If a ManualStop event (Event 2) is issued in the OpenSent state, the local system:
OpenStopd状態でManualStopイベント（イベント2）が発行されると、ローカルシステムは次のことを行います。
- sends the NOTIFICATION with a 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.
- 状態をアイドルに変更します。
If an AutomaticStop event (Event 8) is issued in the OpenSent state, the local system:
OpenSent状態でAutomaticStopイベント（イベント8）が発行されると、ローカルシステムは次のことを行います。
- sends the NOTIFICATION with a Cease,
- NOTIFICATIONを停止して送信し、
- sets the ConnectRetryTimer to zero,
- ConnectRetryTimerをゼロに設定し、
- releases all the 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.
- 状態をアイドルに変更します。
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.
- 状態をアイドルに変更します。
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接続は、OPENメッセージが受信されるまで、接続衝突処理（セクション6.8）ごとに追跡されます。
A TCP Connection Request for an Invalid port (Tcp_CR_Invalid (Event 15)) is ignored.
無効なポート（Tcp_CR_Invalid（イベント15））に対するTCP接続要求は無視されます。
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.
- 状態をアクティブに変更します。
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:
OPENメッセージを受信すると、すべてのフィールドが正しいかどうかがチェックされます。 OPENメッセージ（イベント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),
- ネゴシエートされた値に応じてHoldTimerを設定します（セクション4.2を参照）。
- 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フィールドの値がローカルの自律システム番号と同じである場合、接続は「内部」接続です。それ以外の場合は、「外部」接続です。 （これは、以下で説明するように、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）またはOPENメッセージチェックでエラー（イベント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.
- 状態をアイドルに変更します。
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
有効なBGP OPENメッセージが受信された場合（イベント19またはイベント20）、衝突検出メカニズム（セクション6.8）を適用する必要があります。比較の詳細については、セクション6.8を参照してください。あ
CollisionDetectDump event occurs when the BGP implementation determines, by means outside the scope of this document, that a connection collision has occurred.
CollisionDetectDumpイベントは、BGP実装が、このドキュメントの範囲外で、接続の衝突が発生したと判断したときに発生します。
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,
- 中止の通知を送信し、
- 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.
- 状態をアイドルに変更します。
If a NOTIFICATION message is received with a version error (Event 24), the local system:
NOTIFICATIONメッセージがバージョンエラー（イベント24）とともに受信された場合、ローカルシステムは次のことを行います。
- sets the ConnectRetryTimer to zero,
- ConnectRetryTimerをゼロに設定し、
- releases all BGP resources,
- すべてのBGPリソースを解放し、
- drops the TCP connection, and
- TCP接続をドロップし、
- changes its state to Idle.
- 状態をアイドルに変更します。
In response to any other event (Events 9, 11-13, 20, 25-28), the local system:
その他のイベント（イベント9、11〜13、20、25〜28）に応じて、ローカルシステムは次のことを行います。
- sends the NOTIFICATION with the Error Code Finite State 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増やします。
- (optionally) performs peer oscillation damping if the DampPeerOscillations attribute is set to TRUE, and
- （オプション）DampPeerOscillations属性がTRUEに設定されている場合、ピア振動減衰を実行します。
- changes its state to 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.
Any start event (Events 1, 3-7) is ignored in the OpenConfirm state.
In response to a ManualStop event (Event 2) initiated by the operator, the local system:
オペレーターによって開始されたManualStopイベント（イベント2）に応答して、ローカルシステム：
- sends the NOTIFICATION message with a Cease,
- NOTIFICATIONメッセージを中止して送信します。
- releases all BGP resources,
- すべてのBGPリソースを解放し、
- drops the TCP connection,
- drops the TCP connection,
- sets the ConnectRetryCounter to zero,
- ConnectRetryCounterをゼロに設定し、
- sets the ConnectRetryTimer to zero, and
- ConnectRetryTimerをゼロに設定し、
- changes its state to Idle.
- 状態をアイドルに変更します。
In response to the AutomaticStop event initiated by the system (Event 8), the local system:
システムによって開始されたAutomaticStopイベント（イベント8）に応答して、ローカルシステムは次のことを行います。
- sends the NOTIFICATION message with a Cease,
- sends the NOTIFICATION message with a Cease,
- sets the ConnectRetryTimer to zero,
- ConnectRetryTimerをゼロに設定し、
- releases all BGP resources,
- releases all BGP resources,
- 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
- (optionally) performs peer oscillation damping if the DampPeerOscillations attribute is set to TRUE, and
- changes its state to Idle.
- 状態をアイドルに変更します。
If the HoldTimer_Expires event (Event 10) occurs before a KEEPALIVE message is received, the local system:
KEEPALIVEメッセージを受信する前にHoldTimer_Expiresイベント（イベント10）が発生した場合、ローカルシステムは次のことを行います。
- sends the NOTIFICATION message with the Error Code Hold Timer Expired,
- sends the NOTIFICATION message with the Error Code Hold Timer Expired,
- 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
- (optionally) performs peer oscillation damping if the DampPeerOscillations attribute is set to TRUE, and
- changes its state to 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
- restarts the KeepaliveTimer, and
- 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.
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.
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:
If the local system receives a TcpConnectionFails event (Event 18) from the underlying TCP or a NOTIFICATION message (Event 25), the local system:
- 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.
- changes its state to Idle.
If the local system receives a NOTIFICATION message with a version error (NotifMsgVerErr (Event 24)), the local system:
ローカルシステムがバージョンエラーのあるNOTIFICATIONメッセージを受信した場合（NotifMsgVerErr（イベント24））、ローカルシステムは次のことを行います。
- sets the ConnectRetryTimer to zero,
- ConnectRetryTimerをゼロに設定し、
- releases all BGP resources,
- すべてのBGPリソースを解放し、
- drops the TCP connection, and
- TCP接続をドロップし、
- changes its state to 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:
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:
- sends a NOTIFICATION with a Cease,
- 中止の通知を送信し、
- sets the ConnectRetryTimer to zero,
- sets the ConnectRetryTimer to zero,
- 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.
- 状態をアイドルに変更します。
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:
OPENメッセージが受信されると、すべてのフィールドが正しいかどうかがチェックされます。 BGPメッセージヘッダーチェック（BGPHeaderErr（イベント21））またはOPENメッセージチェックでエラーが検出された場合（セクション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,
- drops the TCP connection,
- increments the ConnectRetryCounter by 1,
- ConnectRetryCounterを1増やします。
- (optionally) performs peer oscillation damping if the DampPeerOscillations attribute is set to TRUE, and
- (optionally) performs peer oscillation damping if the DampPeerOscillations attribute is set to TRUE, and
- changes its state to 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:
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:
- sends a NOTIFICATION with a Cease,
- sends a NOTIFICATION with a 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.
- 状態をアイドルに変更します。
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、20、27〜28）に応じて、ローカルシステムは次のことを行います。
- sends a NOTIFICATION with a code of Finite State Machine Error,
- sends a NOTIFICATION with a code of Finite State Machine Error,
- sets the ConnectRetryTimer to zero,
- ConnectRetryTimerをゼロに設定し、
- releases all BGP resources,
- すべてのBGPリソースを解放し、
- drops the TCP connection,
- drops the TCP connection,
- increments the ConnectRetryCounter by 1,
- increments the ConnectRetryCounter by 1,
- (optionally) performs peer oscillation damping if the DampPeerOscillations attribute is set to TRUE, and
- (optionally) performs peer oscillation damping if the DampPeerOscillations attribute is set to TRUE, and
- changes its state to 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.
確立済みの状態では、開始イベント（イベント1、3〜7）は無視されます。
In response to a ManualStop event (initiated by an operator) (Event 2), the local system:
In response to a ManualStop event (initiated by an operator) (Event 2), the local system:
- sends the NOTIFICATION message with a Cease,
- NOTIFICATIONメッセージを中止して送信します。
- sets the ConnectRetryTimer to zero,
- sets the ConnectRetryTimer to zero,
- deletes all routes associated with this connection,
- この接続に関連付けられているすべてのルートを削除し、
- releases BGP resources,
- releases BGP resources,
- drops the TCP connection,
- TCP接続をドロップし、
- sets the ConnectRetryCounter to zero, and
- ConnectRetryCounterをゼロに設定し、
- changes its state to Idle.
- 状態をアイドルに変更します。
In response to an AutomaticStop event (Event 8), the local system:
In response to an AutomaticStop event (Event 8), the local system:
- sends a NOTIFICATION with a 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.
- changes its state to Idle.
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:
If the HoldTimer_Expires event occurs (Event 10), the local system:
- 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.
- 状態をアイドルに変更します。
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.
- restarts its KeepaliveTimer, unless the negotiated HoldTime value is zero.
Each time the local system sends a KEEPALIVE or UPDATE message, it restarts its KeepaliveTimer, unless the negotiated HoldTime value is zero.
ローカルシステムは、KEEPALIVEまたはUPDATEメッセージを送信するたびに、ネゴシエートされたHoldTime値がゼロでない限り、KeepaliveTimerを再起動します。
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.
An invalid TCP connection (Tcp_CR_Invalid event (Event 15)) will be ignored.
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またはイベント17）に応答して、2番目の接続は、OPENメッセージを送信するまで追跡される必要があります（SHALL）。
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:
有効なOPENメッセージ（BGPOpen（イベント19））が受信され、CollisionDetectEstablishedStateオプション属性がTRUEの場合、OPENメッセージは他の接続と衝突（6.8）しているかどうかを確認するためにチェックされます。 BGP実装がこの接続を終了する必要があると判断した場合、OpenCollisionDumpイベント（イベント23）を処理します。この接続を終了する必要がある場合、ローカルシステムは次のことを行います。
- sends a NOTIFICATION with a Cease,
- sends a NOTIFICATION with a Cease,
- sets the ConnectRetryTimer to zero,
- ConnectRetryTimerをゼロに設定し、
- deletes all routes associated with this connection,
- 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.
- 状態をアイドルに変更します。
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:
ローカルシステムが、基になるTCPからNOTIFICATIONメッセージ（イベント24またはイベント25）またはTcpConnectionFails（イベント18）を受信した場合、ローカルシステムは次のことを行います。
- sets the ConnectRetryTimer to zero,
- ConnectRetryTimerをゼロに設定し、
- deletes all routes associated with this connection,
- この接続に関連付けられているすべてのルートを削除し、
- releases all the BGP resources,
- releases all the BGP resources,
- drops the TCP connection,
- TCP接続をドロップし、
- increments the ConnectRetryCounter by 1,
- increments the ConnectRetryCounter by 1,
- changes its state to Idle.
- 状態をアイドルに変更します。
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.
- remains in the Established state.
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.
- remains in the Established state.
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,
- 更新エラーを含む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.
- 状態をアイドルに変更します。
In response to any other event (Events 9, 12-13, 20-22), the local system:
その他のイベント（イベント9、12〜13、20〜22）に応答して、ローカルシステムは次のことを行います。
- sends a NOTIFICATION message with the Error Code Finite State Machine Error,
- エラーコードの有限状態マシンエラーを含むNOTIFICATIONメッセージを送信します。
- deletes all routes associated with this connection,
- この接続に関連付けられているすべてのルートを削除し、
- sets the ConnectRetryTimer to zero,
- sets the ConnectRetryTimer to zero,
- releases all BGP resources,
- すべてのBGPリソースを解放し、
- drops the TCP connection,
- drops the TCP connection,
- increments the ConnectRetryCounter by 1,
- ConnectRetryCounterを1増やします。
- (optionally) performs peer oscillation damping if the DampPeerOscillations attribute is set to TRUE, and
- (optionally) performs peer oscillation damping if the DampPeerOscillations attribute is set to TRUE, and
- changes its state to Idle.
- 状態をアイドルに変更します。
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.
UPDATEメッセージは、確立済み状態でのみ受信できます。その他の状態でUPDATEメッセージを受信すると、エラーになります。セクション6.3で指定されているように、UPDATEメッセージを受信すると、各フィールドの有効性がチェックされます。
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.
オプションの非推移的属性が認識されない場合、静かに無視されます。オプションの推移属性が認識されない場合、属性フラグオクテットの部分ビット（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.
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.
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-Inは次のようにこのルートで更新されます。新しいルートのNLRIが、現在ルートがAdj-RIB-Inに格納しているものと同一である場合、新しいルートは、Adj-RIB-Inの古いルートを置き換える必要があるため、暗黙的に古いルートをサービスから撤回します。それ以外の場合、Adj-RIB-Inに新しいルートと同じNLRIのルートがない場合、新しいルートはAdj-RIB-Inに配置される必要があります。
Once the BGP speaker updates the Adj-RIB-In, the speaker SHALL run its Decision Process.
BGPスピーカーがAdj-RIB-Inを更新すると、スピーカーは決定プロセスを実行する必要があります（SHALL）。
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.
決定プロセスでは、ローカルのポリシー情報ベース（PIB）のポリシーをAdj-RIBs-Inに格納されているルートに適用することにより、後続のアドバタイズメントのルートを選択します。決定プロセスの出力は、ピアにアドバタイズされるルートのセットです。選択したルートは、ポリシーに従って、ローカルスピーカーのAdj-RIBs-Outに保存されます。
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決定プロセスは概念的なものであり、実装が説明された機能をサポートし、それらが外部から見える同じ動作を示す限り、説明どおりに実装する必要はありません。
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:
決定プロセスは、Adj-RIBs-Inに含まれるルートを操作し、以下の責任があります。
- selection of routes to be used locally by the speaker
- 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:
決定プロセスは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の完了時に呼び出されます。フェーズ2は、個別の宛先ごとに使用可能なすべてのルートから最適なルートを選択し、選択した各ルートをLoc-RIBにインストールします。
c) Phase 3 is invoked after the Loc-RIB has been modified. It is responsible for disseminating routes in the Loc-RIB to each peer, according to the policies contained in the PIB. Route aggregation and information reduction can optionally be performed within this phase.
c) フェーズ3は、Loc-RIBが変更された後に呼び出されます。 PIBに含まれているポリシーに従って、Loc-RIB内のルートを各ピアに配布します。ルート集約と情報削減は、このフェーズ内でオプションで実行できます。
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.
フェーズ1決定機能は、ローカルBGPスピーカーがピアから、新しいルート、置換ルート、または撤回されたルートをアドバタイズするUPDATEメッセージを受信するたびに呼び出されます。
The Phase 1 decision function is a separate process,f which completes when it has no further work to do.
フェーズ1の決定機能は別のプロセスであり、それ以上の作業がなくなると完了します。
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.
フェーズ1の決定機能は、Adj-RIB-Inに含まれるルートを操作する前にロックし、Adj-RIB-Inに含まれるすべての新しいルートまたは実行不可能なルートを操作した後にロックを解除します。
For each newly received or replacement feasible route, the local BGP speaker determines a degree of preference as follows:
新しく受信したルートまたは置き換え可能なルートごとに、ローカルBGPスピーカーは次のように優先度を決定します。
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スピーカーは、事前構成されたポリシー情報に基づいて優先度を計算します。戻り値がルートが不適格であることを示している場合、そのルートはルート選択の次のフェーズへの入力として機能しない場合があります。それ以外の場合、戻り値は、IBGP読み取り広告でLOCAL_PREF値として使用する必要があります。
The exact nature of this policy information, and the computation involved, is a local matter.
このポリシー情報の正確な性質、および関連する計算は、ローカルな問題です。
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.
フェーズ2の決定機能は、フェーズ1の完了時に呼び出されます。フェーズ2の機能は、別のプロセスであり、実行する作業がなくなると完了します。フェーズ2プロセスでは、Adj-RIBs-Inで適格なすべてのルートが考慮されます。
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.
フェーズ2の決定関数は、フェーズ3の決定関数の処理中に実行をブロックされます。フェーズ2機能は、その機能を開始する前にすべてのAdj-RIB-Inをロックし、完了時にそれらをロック解除します。
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ルートのNEXT_HOP属性が解決できないアドレスを示している場合、またはルートがルーティングテーブルにインストールされている場合に解決できなくなる場合は、BGPルートをフェーズ2決定機能から除外する必要があります。
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ルートをフェーズ2決定機能から除外する必要があります。 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-Inに実行可能なルートが存在する宛先のセットごとに、ローカル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) is the only route to that destination, or
c) is selected as a result of the Phase 2 tie breaking rules specified in Section 9.1.2.2.
c) is selected as a result of the Phase 2 tie breaking rules specified in Section 9.1.2.2.
The local speaker SHALL then install that route in the Loc-RIB, replacing any route to the same destination that is currently being held in the Loc-RIB. 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.
ローカルスピーカーはそのルートをLoc-RIBにインストールする必要があり（SHALL）、現在Loc-RIBで保持されている同じ宛先へのルートを置き換えます。新しいBGPルートがルーティングテーブルにインストールされている場合、同じ宛先への現在無効と見なされている既存のルートがルーティングテーブルから削除されるように注意する必要があります。新しいBGPルートがルーティングテーブルの既存の非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.
ローカルスピーカーは、選択されたルートのNEXT_HOP属性から直接次のホップアドレスを決定する必要があります（セクション5.1.3を参照）。 NEXT_HOP（NEXT_HOPがIGPルートを介して解決される）への直接のネクストホップまたはIGPコストが変更された場合、フェーズ2ルート選択を再度実行する必要があります。
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ルートを直接のネクストホップでルーティングテーブルにインストールする必要はありませんが、実装では、パケットがBGPルートに沿って転送される前に、関連するNEXT_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).
解決できないルートは、Loc-RIBとルーティングテーブルから削除する必要があります。ただし、対応する解決できないルートはAdj-RIBs-Inに保持する必要があります（解決できる場合）。
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スピーカーはフェーズ2の決定から解決できないルートを除外する必要があります（SHOULD）。これにより、Loc-RIBとルーティングテーブルに有効なルートのみがインストールされます。
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の中間ネットワークアドレスと一致し、Rte1を通じて（直接的または間接的に）再帰的に解決されない解決可能なルートRte2が少なくとも1つ含まれている場合、中間ネットワークアドレスのみを参照するルート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）参照されているインターフェースの状態がupであり、このインターフェースで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ルートはインターフェイスを参照しませんが、両方のタイプ（インターフェイスを指定するルートまたはインターフェイスを指定しないルート）のルーティングテーブルのルートを介して解決できます。 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ルートのNEXT_HOPと一致するルートが含まれていない場合、BGPルートは解決できないと見なされることに注意してください。相互に再帰的なルート（互いに解決するルートまたは自分自身で解決するルート）も、解決可能性チェックに失敗します。
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 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.
ルーティングテーブルの現在の内容を使用してNEXT_HOPが解決可能であっても、実装がルーティングテーブルにインストールされている場合に解決できなくなる可能性のあるルートを実装が考慮しないことも重要です（このようなルートの例は相互再帰ルートです） 。このチェックにより、BGPスピーカーが、ルーティングテーブルに削除され、スピーカーによって使用されないルートがインストールされないようにします。したがって、ローカルルーティングテーブルの安定性に加えて、このチェックはネットワーク内のプロトコルの動作も改善します。
Whenever a BGP speaker identifies a route that fails the resolvability check because of mutual recursion, an error message SHOULD be logged.
BGPスピーカーが相互再帰のために解決可能性チェックに失敗したルートを特定するときはいつでも、エラーメッセージがログに記録されるべきです（SHOULD）。
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-Inで、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スピーカーが、ルートのNEXT_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番号の数が最も少ないために関連付けられていないすべてのルートを考慮から削除します。この数をカウントするとき、セットに含まれるASの数に関係なく、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番号を持つために関連付けられていないすべてのルートを考慮から削除します。
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
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属性がない場合、関数は可能な限り低いMULTI_EXIT_DISC値（つまり0）を返します。
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です。ルートがIBGPを介して学習され、他のIBGPスピーカーが（a）ルートを発信したか、または（b）集約によってルートを作成し、集約ルートのAS_PATH属性が空であるか、AS_SETで始まっている場合、それはローカル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を削除することを選択した場合、MULTI_EXIT_DISCのオプションの比較は、実行される場合、EBGPで学習されたルート間でのみ実行される必要があります。次に、MULTI_EXIT_DISC属性を削除した後、EBGPで学習した最適なルートをIBGPで学習したルートと比較できます。 MULTI_EXIT_DISCがEBGP学習ルートのサブセットから削除され、選択された「最良の」EBGP学習ルートでMULTI_EXIT_DISCが削除されない場合、IBGP学習ルートとの比較でMULTI_EXIT_DISCを使用する必要があります。 IBGPで学習されたルートの場合、決定プロセスのこのステップに到達するルート比較でMULTI_EXIT_DISCを使用する必要があります。 EBGP学習ルートのMULTI_EXIT_DISCをIBGP学習ルートとの比較に含め、次にMULTI_EXIT_DISC属性を削除し、ルートをアドバタイズすると、ルートループが発生することが証明されています。
d) If at least one of the candidate routes was received via EBGP, remove from consideration all routes that were received via IBGP.
d) 候補ルートの少なくとも1つがEBGP経由で受信された場合は、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) 優先度の低い内部コストのルートを考慮から外します。ルートの内部コストは、ルーティングテーブルを使用してルートのNEXT_HOPへのメトリックを計算することにより決定されます。ルートのNEXT_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
m =すべてのルートを検討中n =すべてのルートを検討中（cost（n）がcost（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.
上記の疑似コードでは、cost（n）は、ルートのNEXT_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 ID値を持つBGPスピーカーによってアドバタイズされたルート以外のすべてのルートを考慮から削除します。
g) Prefer the route received from the lowest peer address.
g) 最下位のピアアドレスから受信したルートを優先します。
The Phase 3 decision function is invoked on completion of Phase 2, or when any of the following events occur:
フェーズ3決定関数は、フェーズ2の完了時、または次のいずれかのイベントが発生したときに呼び出されます。
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
c) 新しいBGPスピーカー接続が確立されたとき
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.
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.
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 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).
Loc-RIB内のすべてのルートは、構成されたポリシーに従ってAdj-RIBs-Outに処理されます。このポリシーは、Loc-RIB内のルートが特定のAdj-RIB-Outにインストールされないようにする場合があります。ルートは、宛先と、このルートによって記述されたNEXT_HOPがルーティングテーブルによって適切に転送される場合を除いて、Adj-Rib-Outにインストールする必要はありません（SHALL NOT）。 Loc-RIBのルートが特定のAdj-RIB-Outから除外されている場合、そのAdj-RIB-Outで以前にアドバタイズされたルートは、UPDATEメッセージを使用してサービスから撤回する必要があります（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-Outに追加されることになるローカルポリシーは、このドキュメントの範囲外です。
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-Outとルーティングテーブルの更新が完了すると、ローカルのBGPスピーカーが9.2のUpdate-Sendプロセスを実行します。
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スピーカーは、ネットワーク層到達可能性情報（NLRI）が重複しているルートを別のBGPスピーカーに送信できます。 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
- より具体的ではないルートによってのみ記述された一連の宛先
- a set of destinations described by the overlap of the less specific and the more specific routes
- より具体的ではないルートとより具体的なルートの重複によって記述された一連の宛先
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 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.
BGPスピーカーが重複するルートを受信する場合、決定プロセスは、構成された受け入れポリシーに基づいて両方のルートを考慮する必要があります。より具体的でないルートとより具体的なルートの両方が受け入れられる場合、決定プロセスはLoc-RIBに、具体的でないルートとより具体的なルートの両方をインストールするか、2つのルートを集約してLoc-RIBに集約ルートをインストールする必要があります。両方のルートのNEXT_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スピーカーが集約を選択する場合、集約の形成に使用されるすべてのASをAS_SETに含めるか、ATOMIC_AGGREGATE属性をルートに追加する必要があります。現在、この属性は主に情報を提供するものです。クラスレスルーティングをサポートしないIPルーティングプロトコルの排除と、クラスレスルーティングをサポートしないルーターとホストの実装の排除により、集約を解除する必要がなくなりました。ルートは集約されるべきではありません。特に、ATOMIC_AGGREGATE属性を持つルートは集約解除してはなりません（MUST NOT）。つまり、このルートのNLRIをより具体的にすることはできません。そのようなルートに沿った転送は、IPパケットが実際にルートのAS_PATH属性にリストされているASのみを通過することを保証するものではありません。
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-Sendプロセスは、すべてのピアへのUPDATEメッセージのアドバタイズを担当します。たとえば、決定プロセスで選択されたルートを、同じ自律システムまたは隣接する自律システムにある他の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スピーカーは、そのUPDATEメッセージに含まれるルーティング情報を他の内部ピアに再配布してはなりません（スピーカーがBGPルートリフレクター[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.
ルート選択プロセスのフェーズ3の一部として、BGPスピーカーはそのAdj-RIBs-Outを更新しました。新しくインストールされたすべてのルートと、代替ルートがないすべての新しく実行不可能なルートは、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スピーカーは、そのAdj-RIB-Outから特定の実現可能なBGPルートをアドバタイズすべきではありません（SHOULD NOT）。
Any routes in the Loc-RIB marked as unfeasible SHALL be removed. Changes to the reachable destinations within its own autonomous system SHALL also be advertised in an UPDATE message.
実行不可能としてマークされたLoc-RIB内のルートは削除する必要があります。独自の自律システム内の到達可能な宛先への変更も、UPDATEメッセージで通知されます。
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を参照）により、1つのルートがメッセージに適合しない場合、BGPスピーカーはルートをピアにアドバタイズしてはならず、ローカルでエラーをログに記録することを選択できます（MAY） 。
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メッセージ）の量を制限します。
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スピーカーからピアへの特定の宛先へのルートのアドバタイズメントと撤回の間で経過する必要がある最小時間を決定します。このレート制限手順は宛先ごとに適用されますが、MinRouteAdvertisementIntervalTimerの値はBGPピアごとに設定されます。
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.
BGPスピーカーからピアに送信される2つのUPDATEメッセージは、実行可能なルートをアドバタイズするか、またはいくつかの一般的な宛先セットへの実行不可能なルートを取り消すか、少なくともMinRouteAdvertisementIntervalTimerで分離する必要があります。これは、共通の宛先セットごとに個別のタイマーを維持することによってのみ達成できます。これは不当なオーバーヘッドになります。 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は、外部ピアに使用されるMinRouteAdvertisementIntervalTimerよりも短くする必要があります（b）このセクションで説明する手順は、内部ピアに送信されるルートには適用しないでください（SHOULD NOT） 。
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の期限が切れるのを待っている間に新しいルートが複数回選択された場合、最後に選択されたルートがMinRouteAdvertisementIntervalTimerの最後にアドバタイズされる必要があります。
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メッセージの連続するアドバタイズメントの間に経過する必要がある最小時間を決定します。
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.
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.
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:
意思決定プロセスでは、オプションで、次のいずれかの方法でAdj-RIBs-Outに配置する情報の量を減らすことができます。
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_PATHs：
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パス情報は、順序付けられたAS_SEQUENCEまたは順序付けされていないAS_SETとして表すことができます。 AS_SETは、9.2.2.2項で説明するルート集約アルゴリズムで使用されます。集約された複数のAS_PATHに出現した回数に関係なく、各AS番号を1回だけリストすることで、AS_PATH情報のサイズを削減します。
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_SETは、ルーティング情報のループを回避するのに十分な情報を提供します。ただし、これらのパスはAS_SEQUENCEの形式で個別にリストされなくなったため、これらの使用により、実現可能な可能性のあるパスが除去される場合があります。実際には、IPパケットが自律システムのグループのエッジに到着すると、BGPスピーカーはより詳細なパス情報を持ち、個々のパスを宛先から区別できるため、これは問題にはなりません。
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.
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.
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スピーカーと交換する必要がある情報の量が減少します。ルートを集約するには、次の手順を個別に、同じタイプのパス属性とネットワーク層到達可能性情報に適用します。
Routes that have different MULTI_EXIT_DISC attributes SHALL NOT be aggregated.
異なるMULTI_EXIT_DISC属性を持つルートは集約されません。
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がある場合、ルートを開始するルーターは、このルートでMULTI_EXIT_DISC属性を通知する必要があります（SHOULD NOT）。
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.
NEXT_HOP：異なるNEXT_HOP属性を持つルートを集約する場合、集約されたルートのNEXT_HOP属性は、集約を実行するBGPスピーカー上のインターフェイスを識別するものとします（SHALL）。
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 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.
AS_PATH attribute: If routes to be aggregated have identical AS_PATH attributes, then the aggregated route has the same AS_PATH attribute as each individual route.
AS_PATH属性：集約されるルートが同じAS_PATH属性を持っている場合、集約されたルートは各個別のルートと同じAS_PATH属性を持ちます。
For the purpose of aggregating AS_PATH attributes, we model each AS within the AS_PATH attribute as a tuple <type, value>, where "type" identifies a type of the path segment the AS belongs to (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_PATH属性を集約するために、AS_PATH属性内の各ASをタプル<type、value>としてモデル化します。ここで、「type」は、ASが属するパスセグメントのタイプを識別します（例：AS_SEQUENCE、AS_SET）。値」はAS番号を識別します。集約されるルートが異なるAS_PATH属性を持っている場合、集約されたAS_PATH属性は以下のすべての条件を満たす必要があります。
- 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内のタイプAS_SEQUENCEのすべてのタプルは、集約されるルートの初期セットのすべてのAS_PATHに表示されます。
- 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のタイプAS_SETのすべてのタプルは、初期セットのAS_PATHの少なくとも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のタプルYの前にある、集約されたAS_PATHのタイプAS_SEQUENCEのタプルXの場合、Yのタイプに関係なく、Yを含む初期セットの各AS_PATHのXはYに先行します。
- No tuple of type AS_SET with the same value SHALL appear more than once in the aggregated AS_PATH.
- 同じ値を持つタイプAS_SETのタプルは、集約されたAS_PATHに2回以上出現することはできません。
- 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.
- 同じ値を持つタイプAS_SEQUENCEの複数のタプルは、同じタイプおよび値の別のタプルに隣接している場合にのみ、集約された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:
実装では、これらのルールに準拠する任意のアルゴリズムを選択できます。少なくとも、適合実装は、上記の条件のすべてを満たす次のアルゴリズムを実行できる必要があります。
- 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属性に共通する（上記で定義された）タプルの最長の先行シーケンスを決定します。このシーケンスを、集約された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属性から残りのタプルのタイプを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に同じ値のタプルが複数ある場合（タプルのタイプに関係なく）、集約されたAS_PATH属性からタイプAS_SETのタプルを削除して、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内の隣接するタプルの各ペアについて、両方のタプルが同じタイプである場合は、255を超える長さのセグメントが生成されない限り、それらをマージします。
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.
ATOMIC_AGGREGATE：集約されるルートの少なくとも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：集約されるルートからのAGGREGATOR属性は、集約されたルートに含まれてはいけません（MUST NOT）。ルート集約を実行するBGPスピーカーは、新しいAGGREGATOR属性をアタッチしてもよい（セクション5.1.7を参照）。
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は不安定なルートの使用を避けるべきであり、ルートの選択に迅速で自然な変更を加えるべきではありません。 「前の文から」「不安定」および「迅速」という用語を定量化するには経験が必要ですが、その原理は明確です。不安定なルートは「ペナルティ」になる可能性があります（[RFC2439]で説明されている手順を使用するなど）。
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ルートを発信するBGPスピーカーは、決定プロセス（セクション9.1を参照）を通過させることにより、これらのルートに優先度（たとえば、ローカル構成に応じて）を割り当てます。これらのルートは、更新プロセスの一部としてローカルAS内の他のBGPスピーカーにも配信される場合があります（セクション9.2を参照）。 BGPを介してAS内で非BGP取得ルートを配布するかどうかの決定は、AS内の環境（IGPのタイプなど）に依存し、構成によって制御する必要があります（SHOULD）。
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つのタイマーを使用します：ConnectRetryTimer（セクション8を参照）、HoldTimer（セクション4.2を参照）、KeepaliveTimer（セクション8を参照）、MinASOriginationIntervalTimer（セクション9.2.1.2を参照）、およびMinRouteAdvertisementIntervalTimer（セクション9.2.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によるIdleHoldTimer（セクション8を参照）。セクション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の推奨デフォルト値はHoldTimeの1/3です。
The suggested default value for the MinASOriginationIntervalTimer is 15 seconds.
The suggested default value for the MinASOriginationIntervalTimer is 15 seconds.
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の実装では、HoldTimerをピアごとに構成できるようにする必要があり、他のタイマーを構成できるようにする必要があります（MAY）。
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メッセージの配信にピークが含まれる可能性を最小限に抑えるには、MinASOriginationIntervalTimer、KeepaliveTimer、MinRouteAdvertisementIntervalTimer、およびConnectRetryTimerに関連付けられたタイマーにジッターを適用する必要があります（SHOULD）。特定のBGPスピーカーは、更新の送信先に関係なく、これらの各量に同じジッターを適用できます（MAY）。つまり、ジッターをピアごとに設定する必要はありません。
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.
推奨されるデフォルトのジッタ量は、適切なタイマーのベース値にランダム係数を掛けることによって決定する必要があります。ランダム係数は、0.75から1.0の範囲で均一に分布します。タイマーが設定されるたびに、新しいランダム値を選択する必要があります。ジッタのランダム値の範囲は構成可能である場合があります。
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ルートリフレクター[RFC2796]、BGPコンフェデレーション[RFC3065]、BGPルートリフレッシュ[RFC2918]などの機能の使用を反映するための変更。
Clarification of the use of the BGP Identifier in the AGGREGATOR attribute.
AGGREGATOR属性でのBGP IDの使用の明確化。
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.
AS間トラフィックエンジニアリングの目的で、BGPスピーカーが自身のASの複数のインスタンスをAS_PATH属性に含める機能。
Clarification of the various types of NEXT_HOPs.
さまざまなタイプのNEXT_HOPの明確化。
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.
直接のネクストホップと、NEXT_HOPパス属性で指定されたネクストホップとの関係。
Clarification of the tie-breaking procedures.
タイブレイク手順の明確化。
Clarification of the frequency of route advertisements.
ルートアドバタイズメントの頻度の明確化。
Optional Parameter Type 1 (Authentication Information) has been deprecated.
オプションパラメータタイプ1（認証情報）は非推奨になりました。
UPDATE Message Error subcode 7 (AS Routing Loop) has been deprecated.
UPDATEメッセージエラーサブコード7（ASルーティングループ）は非推奨になりました。
OPEN Message Error subcode 5 (Authentication Failure) has been deprecated.
OPENメッセージエラーサブコード5（認証失敗）は非推奨になりました。
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の明確化。
All the changes listed in Appendix A, plus the following.
付録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は、到達可能な宛先のセットが単一の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が導入され、特定の集計が非集計にならないようになりました。別の新しい属性であるAGGREGATORを追加して、集約ルートを集約し、集約を引き起こしたASおよびそのAS内のどのBGPスピーカーをアドバタイズできます。
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.
ホールドタイマーを対称にするために、ホールドタイマーは接続ごとにネゴシエートされるようになりました。ゼロのホールドタイマーがサポートされるようになりました。
All of the changes listed in Appendices A and B, plus the following.
付録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 ID）がOPENメッセージに追加されました。衝突を検出して回復する手順を指定するために、新しいテキスト（セクション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.
新しいドキュメントでは、NEXT_HOPパス属性で渡されるルーターがBGPスピーカーと同じ自律システムの一部になるように制限されなくなりました。
The new document optimizes and simplifies the exchange of information about previously reachable routes.
新しいドキュメントは、以前に到達可能だったルートに関する情報の交換を最適化および簡素化します。
All of the changes listed in Appendices A, B, and C, plus the following.
付録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]有限状態マシンへのマイナー変更は、BSDバージョン4.3で提供されるTCPユーザーインターフェイスに対応するために必要でした。
The notion of Up/Down/Horizontal relations presented in RFC 1105 has been removed from the protocol.
RFC 1105で提示されているUp / Down / Horizontal関係の概念は、プロトコルから削除されました。
The changes in the message format from RFC 1105 are as follows:
RFC 1105からのメッセージ形式の変更は次のとおりです。
1. The Hold Time field has been removed from the BGP header and added to the OPEN message.
1. Hold TimeフィールドがBGPヘッダーから削除され、OPENメッセージに追加されました。
2. The version field has been removed from the BGP header and added to the OPEN message.
2. バージョンフィールドがBGPヘッダーから削除され、OPENメッセージに追加されました。
3. The Link Type field has been removed from the OPEN message.
3. Link TypeフィールドがOPENメッセージから削除されました。
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. マーカーフィールドが拡張され、その役割が認証をサポートするように拡張されました。
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.
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.
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メッセージはPUSHフラグを設定して送信する必要があります（SHOULD）。 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ユーザーインターフェイスがTCP接続のDSCPフィールド[RFC2474]の設定をサポートしている場合、BGPが使用するTCP接続は、DSCPフィールドのビット0〜2を110（バイナリ）に設定して開く必要があります（SHOULD）。
An implementation MUST support the TCP MD5 option [RFC2385].
実装は、TCP MD5オプション[RFC2385]をサポートする必要があります。
This section presents some implementation recommendations.
このセクションでは、実装に関するいくつかの推奨事項を示します。
Appendix F.1. Multiple Networks Per Message
付録F.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つのアドレスプレフィックスを使用すると、受信側のオーバーヘッドが大幅に増加します。複数のメッセージを受信するためにシステムのオーバーヘッドが増加するだけでなく、ルーティングテーブルをスキャンして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.
パス属性セットごとに編成されていないルーティングテーブルからパス属性セットごとに多くのアドレスプレフィックスを含むメッセージを作成する1つの方法は、ルーティングテーブルがスキャンされるときに多くのメッセージを作成することです。各アドレスプレフィックスが処理されると、関連付けられた一連のパス属性のメッセージが存在しない場合は割り当てられ、新しいアドレスプレフィックスが追加されます。そのようなメッセージが存在する場合は、新しいアドレスプレフィックスが追加されます。メッセージに新しいアドレスプレフィックスを保持するスペースがない場合は、メッセージが送信され、新しいメッセージが割り当てられ、新しいアドレスプレフィックスが新しいメッセージに挿入されます。ルーティングテーブル全体がスキャンされると、割り当てられたすべてのメッセージが送信され、そのリソースが解放されます。最大の圧縮は、アドレスプレフィックスでカバーされるすべての宛先が共通のパス属性のセットを共有するときに達成され、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ピアやその他のルーティングプロトコルにフラッシュアップデートが提供されます。このアプローチの欠点は、ルーティング情報の伝搬待ち時間が長くなることです。複数のメッセージを処理するのにかかる時間よりも長くない最小のフラッシュ更新間隔を選択することにより、この待ち時間を最小限に抑える必要があります。より良い方法は、更新を送信する前に受信したすべてのメッセージを読むことです。
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。 AS_SETソート
Another useful optimization that can be done to simplify this situation is to sort the AS numbers found in an AS_SET. This optimization is entirely optional.
この状況を簡略化するために実行できる別の便利な最適化は、AS_SETで見つかったAS番号をソートすることです。この最適化は完全にオプションです。
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バージョンをサポートする実装は、ピアごとにBGP-4のみを話す機能を提供する必要があります。
Appendix F.6. Complex AS_PATH Aggregation
付録F.6。複雑なAS_PATH集約
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属性を集約する目的で、各ASをタプル<type、value>としてモデル化します。ここで、「type」は、ASが属するパスセグメントのタイプ（例：AS_SEQUENCE、AS_SET）、および「value "はAS番号です。 2つのASは、対応する<type、value>タプルが同じである場合、同じであると言います。
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属性内の同じAS（上記で定義）を識別します。 XとYの2つのASは、次の場合に同じ順序であると言います。
- 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で構成され、集約されるAS_PATH属性に現れるのとまったく同じ順序です。 （a）で識別された2つの連続したASが、両方のAS_PATH属性で互いにすぐに集約されない場合、両方の属性の間にあるAS（同じ2つの連続したASの間にあるAS）が結合され、両方のAS_PATH属性からの間にあるASで構成されるAS_SETパスセグメント。次に、このセグメントは、集約された属性の（a）で識別された2つの連続するASの間に配置されます。 （a）で識別された2つの連続するASが1つの属性で互いに直後に続き、別の属性では続かない場合、後者の間にあるASはAS_SETパスセグメントに結合されます。次に、このセグメントは、集約された属性の（a）で識別された2つの連続するASの間に配置されます。
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) 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.
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番号の最後のインスタンス（右端のオカレンス）を除くすべてを集約されたAS_PATH属性から削除する必要があります。
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実装は、RFC 2385 [RFC2385]で指定された認証メカニズムをサポートする必要があります。このメカニズムによって提供される認証は、ピアごとに行うことができます。
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はRFC 2385で定義されたメカニズムの使用を指定します。これらのサービスは、ルーター間のTCP接続に対するアクティブな盗聴攻撃を検出して拒否することを目的としています。これらのセキュリティサービスに影響を与えるメカニズムを使用しないと、攻撃者はこれらのTCP接続を妨害したり、正当なピアルーターになりすますことができます。 RFCで定義されたメカニズムはピアエンティティ認証を提供しないため、これらの接続は、TCP層で検出されない何らかの形の再生攻撃を受ける可能性があります。このような攻撃により、「壊れた」または「なりすましの」BGPメッセージが（TCPから）配信される可能性があります。
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.
RFC 2385で定義されたメカニズムは、通常のTCPチェックサムを、TCPチェックサムと同じデータに対して計算される16バイトのメッセージ認証コード（MAC）で補強します。このMACは、一方向ハッシュ関数（MD5）と秘密鍵の使用に基づいています。キーはピアルータ間で共有され、キーにアクセスできない攻撃者が容易に計算できないMAC値を生成するために使用されます。準拠した実装はこのメカニズムをサポートする必要があり、ネットワーク管理者がピアごとにこれをアクティブ化できるようにする必要があります。
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.
RFC 2385は、MACの計算に使用されるキーの管理（生成、配布、置換など）の方法を規定していません。 RFC 3562 [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.
MACの計算に使用されるキーは定期的に変更して、キーの侵害や成功した暗号解読攻撃の影響を最小限に抑える必要があります。 RFC 3562は、最大で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.
もちろん、攻撃者が推測しにくいように各キーを選択する必要もあります。 RFC 1750で指定されている乱数生成の手法は、キーとして使用できる値を生成するためのガイドを提供します。 RFC 2385は、「80バイト以下の印刷可能なASCII文字列で構成される」キーをサポートする実装を要求しています。 RFC 3562では、このコンテキストで使用されるキーは、12〜24バイトのランダム（疑似ランダム）ビットであることが推奨されています。これは、一般的に16〜20バイトの範囲のキーを使用する類似のMACアルゴリズムの提案とかなり一致しています。この範囲の下限で十分なランダムビットを提供するために、RFC 3562は、一般的なACSIIテキスト文字列がRFC 2385で指定されたキー長の上限に近い必要があることも認めています。
BGP vulnerabilities analysis is discussed in [RFC4272].
BGPの脆弱性分析については、[RFC4272]で説明されています。
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メッセージには8ビットのメッセージタイプが含まれており、IANAが作成し、「BGPメッセージタイプ」という名前のレジストリを維持しています。このドキュメントでは、次のメッセージタイプを定義しています。
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
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]で定義された標準アクションプロセス、または[RFC4020]で定義された早期IANA割り当てプロセスを使用して行われます。割り当ては、名前と値で構成されます。
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メッセージは、1つ以上のパス属性を運ぶ場合があります。各属性には、8ビットの属性タイプコードが含まれます。 IANAはすでに「BGPパス属性」というタイトルのこのようなレジストリを維持しています。このドキュメントでは、次のパス属性タイプコードを定義しています。
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
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]で定義された標準アクションプロセス、または[RFC4020]で定義された早期IANA割り当てプロセスを使用して行われます。割り当ては、名前と値で構成されます。
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メッセージは、IANAが作成し、「BGPエラーコード」という名前のレジストリを維持している8ビットのエラーコードを伝達します。このドキュメントでは、次のエラーコードを定義しています。
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
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]で定義された標準アクションプロセス、または[RFC4020]で定義された早期IANA割り当てプロセスを使用して行われます。割り当ては、名前と値で構成されます。
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ビットのエラーサブコードを伝送します。各サブコードは特定のエラーコードのコンテキスト内で定義する必要があり、したがってそのコンテキスト内でのみ一意でなければなりません。
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は一連のレジストリ「エラーサブコード」を作成し、維持しています。BGPエラーコードごとに個別のレジストリがあります。将来の割り当ては、[RFC2434]で定義された標準アクションプロセス、または[RFC4020]で定義された早期IANA割り当てプロセスを使用して行われます。割り当ては、名前と値で構成されます。
This document defines the following Message Header Error subcodes:
このドキュメントでは、次のメッセージヘッダーエラーサブコードを定義します。
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
This document defines the following OPEN Message Error subcodes:
このドキュメントでは、次のOPENメッセージエラーサブコードを定義しています。
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
This document defines the following UPDATE Message Error subcodes:
このドキュメントでは、次のUPDATEメッセージエラーサブコードを定義しています。
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 Normative References
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC791] Postel、J。、「インターネットプロトコル」、STD 5、RFC 791、1981年9月。
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC793] Postel、J。、「Transmission Control Protocol」、STD 7、RFC 793、1981年9月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, August 1998.
[RFC2385] Heffernan、A。、「TCP MD5署名オプションによるBGPセッションの保護」、RFC 2385、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、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 2434、1998年10月。
Informative References
参考引用
[RFC904] Mills, D., "Exterior Gateway Protocol formal specification", RFC 904, April 1984.
[RFC904] Mills、D。、「Exterior Gateway Protocol formal specification」、RFC 904、1984年4月。
[RFC1092] Rekhter, J., "EGP and policy based routing in the new NSFNET backbone", RFC 1092, February 1989.
[RFC1092] Rekhter、J。、「新しいNSFNETバックボーンにおけるEGPおよびポリシーベースのルーティング」、RFC 1092、1989年2月。
[RFC1093] Braun, H., "NSFNET routing architecture", RFC 1093, February 1989.
[RFC1093] Braun、H。、「NSFNETルーティングアーキテクチャ」、RFC 1093、1989年2月。
[RFC1105] Lougheed, K. and Y. Rekhter, "Border Gateway Protocol (BGP)", RFC 1105, June 1989.
[RFC1105] Lougheed、K。およびY. Rekhter、「Border Gateway Protocol（BGP）」、RFC 1105、1989年6月。
[RFC1163] Lougheed, K. and Y. Rekhter, "Border Gateway Protocol (BGP)", RFC 1163, June 1990.
[RFC1163] Lougheed, K. and Y. Rekhter, "Border Gateway Protocol (BGP)", RFC 1163, June 1990.
[RFC1267] Lougheed, K. and Y. Rekhter, "Border Gateway Protocol 3 (BGP-3)", RFC 1267, October 1991.
[RFC1267] Lougheed、K。およびY. Rekhter、「Border Gateway Protocol 3（BGP-3）」、RFC 1267、1991年10月。
[RFC1771] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, March 1995.
[RFC1771] Rekhter、Y。およびT. Li、「A Border Gateway Protocol 4（BGP-4）」、RFC 1771、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. Gross、「インターネットにおけるボーダーゲートウェイプロトコルの適用」、RFC 1772、1995年3月。
[RFC1518] Rekhter, Y. and T. Li, "An Architecture for IP Address Allocation with CIDR", RFC 1518, September 1993.
[RFC1518] Rekhter、Y。およびT. Li、「CIDRを使用したIPアドレス割り当てのアーキテクチャ」、RFC 1518、1993年9月。
[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] Fuller、V.、Li、T.、Yu、J。、およびK. Varadhan、「Classless Inter-Domain Routing（CIDR）：a Address Assignment and Aggregation Strategy」、RFC 1519、1993年9月。
[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. Bates、「自律システム（AS）の作成、選択、および登録に関するガイドライン」、BCP 6、RFC 1930、1996年3月。
[RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities Attribute", RFC 1997, August 1996.
[RFC1997] Chandra、R.、Traina、P。、およびT. Li、「BGP Communities Attribute」、RFC 1997、1996年8月。
[RFC2439] Villamizar, C., Chandra, R., and R. Govindan, "BGP Route Flap Damping", RFC 2439, November 1998.
[RFC2439] Villamizar、C.、Chandra、R。、およびR. Govindan、「BGP Route Flap Damping」、RFC 2439、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] Nichols、K.、Blake、S.、Baker、F。、およびD. Black、「Definition of the Differentiated Services Field（DS Field）in the IPv4 and IPv6 Headers」、RFC 2474、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の代替」、RFC 2796、2000年4月。
[RFC2858] Bates, T., Rekhter, Y., Chandra, R., and D. Katz, "Multiprotocol Extensions for BGP-4", RFC 2858, June 2000.
[RFC2858]ベイツ、T。、レクター、Y。、チャンドラ、R。、およびD.カッツ、「BGP-4のマルチプロトコル拡張機能」、RFC 2858、2000年6月。
[RFC3392] Chandra, R. and J. Scudder, "Capabilities Advertisement with BGP-4", RFC 3392, November 2002.
[RFC3392] Chandra、R。およびJ. Scudder、「Capabilities Advertisement with BGP-4」、RFC 3392、2002年11月。
[RFC2918] Chen, E., "Route Refresh Capability for BGP-4", RFC 2918, September 2000.
[RFC2918] Chen, E., "Route Refresh Capability for BGP-4", RFC 2918, September 2000.
[RFC3065] Traina, P., McPherson, D., and J. Scudder, "Autonomous System Confederations for BGP", RFC 3065, February 2001.
[RFC3065] Traina、P.、McPherson、D。、およびJ. Scudder、「BGPの自律システム連合」、RFC 3065、2001年2月。
[RFC3562] Leech, M., "Key Management Considerations for the TCP MD5 Signature Option", RFC 3562, July 2003.
[RFC3562] Leech、M。、「TCP MD5署名オプションのキー管理に関する考慮事項」、RFC 3562、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]「情報処理システム-システム間のテレコミュニケーションおよび情報交換-ISO 8473 PDUの転送をサポートするための中間システム間でのドメイン間ルーティング情報の交換のためのプロトコル」、ISO / IEC IS10747、1993。
[RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", RFC 4272, January 2006
[RFC4272]マーフィーS。、「BGPセキュリティ脆弱性分析」、RFC 4272、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. Zinin、「Early IANA Allocation of Standards Track Code Points」、BCP 100、RFC 4020、2005年2月。
Editors' Addresses
編集者のアドレス
Yakov Rekhter Juniper Networks
Yakov Rekhter Juniper Networks
EMail: yakov@juniper.net
Tony Li
トニー・リー|
EMail: tony.li@tony.li
Susan Hares NextHop Technologies, Inc. 825 Victors Way Ann Arbor, MI 48108
スーザンハレスNextHop Technologies、Inc. 825 Victors Wayアンアーバー、ミシガン州48108
Phone: (734)222-1610 EMail: skh@nexthop.com
Phone: (734)222-1610 EMail: skh@nexthop.com
Full Copyright Statement
完全な著作権表示
Copyright (C) The Internet Society (2006).
Copyright（C）The Internet Society（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.
このドキュメントは、BCP 78に含まれる権利、ライセンス、および制限の対象であり、そこに記載されている場合を除き、著者はすべての権利を保持します。
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.
このドキュメントとここに含まれる情報は、「現状のまま」で提供され、寄稿者、彼/彼女の代理人、または（もしあれば）組織、インターネットエンジニアリングおよびインターネットエンジニアリングタスクフォースは、すべての保証を明示的または明示的に提供します。ここに含まれる情報の使用により、商品性または特定の目的への適合性に関するいかなる権利または黙示の保証も侵害されないという保証を含みますが、これに限定されるものではありません。
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は、このドキュメントに記載されているテクノロジーの実装または使用に関連すると主張される可能性がある知的財産権またはその他の権利の有効性または範囲、またはそのような権利に基づくライセンスが適用されるかどうかに関係なく、いかなる立場も取りません。利用できる;また、そのような権利を特定するために独立した取り組みを行ったことを表すものでもありません。 RFC文書の権利に関する手順に関する情報は、BCP 78およびBCP 79にあります。
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.
IETF事務局に対して行われたIPR開示のコピー、および利用可能になるライセンスの保証、または一般ライセンスを取得しようとした試み、またはこの仕様の実装者またはユーザーがそのような所有権を使用するための許可を取得した結果を取得できます。 http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
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は、この規格を実装するために必要となる可能性のある技術をカバーする可能性のある著作権、特許、特許出願、またはその他の所有権に注意を向けるよう、関係者に呼びかけます。 IEETのietf-ipr@ietf.orgに情報を送信してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディター機能の資金は、IETF管理サポート活動（IASA）によって提供されます。