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