RFC1105 日本語訳
1105 Border Gateway Protocol (BGP). K. Lougheed, Y. Rekhter. June 1989. (Format: TXT=37644 bytes) (Obsoleted by RFC1163) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group K. Lougheed
Request for Comments: 1105 cisco Systems
Y. Rekhter
T.J. Watson Research Center, IBM Corp.
June 1989
コメントを求めるワーキンググループK.ロッキードの要求をネットワークでつないでください: 1105年のコクチマスSystems Y.Rekhter T.J.ワトソン研究所、IBM社の1989年6月
A Border Gateway Protocol (BGP)
ボーダ・ゲイトウェイ・プロトコル(BGP)
Status of this Memo
このMemoの状態
This RFC outlines a specific approach for the exchange of network reachability information between Autonomous Systems.
このRFCはAutonomous Systemsの間のネットワーク可到達性情報の交換のための特定のアプローチについて概説します。
At the time of this writing, the Border Gateway Protocol implementations exist for cisco routers as well as for the NSFNET Nodal Switching Systems. A public domain version for "gated" is currently being implemented.
この書くこと時点で、ボーダ・ゲイトウェイ・プロトコル実装はコクチマスルータとNSFNET Nodal Switching Systemsのために存在します。「ゲート」のための公共の場バージョンは現在、実装されています。
Distribution of this memo is unlimited.
このメモの分配は無制限です。
1. Introduction
1. 序論
The Border Gateway Protocol (BGP) is an inter-autonomous system routing protocol. It is built on experience gained with EGP as defined in RFC 904 [1] and EGP usage in the NSFNET Backbone as described in RFC 1092 [2] and RFC 1093 [3].
ボーダ・ゲイトウェイ・プロトコル(BGP)は相互自律システムルーティング・プロトコルです。 それはEGPと共にNSFNET BackboneのRFC904[1]とEGP用法で定義されるように行われた経験のときにRFC1092[2]とRFC1093[3]で説明されるように建てられます。
The primary function of a BGP speaking system is to exchange network reachability information with other BGP systems. This network reachability information includes information on the autonomous systems (AS's) that traffic must transit to reach these networks. This information is sufficient to construct a graph of AS connectivity from which routing loops may be pruned and policy decisions at an AS level may be enforced.
BGPがシステムを話すプライマリ機能は他のBGPシステムとネットワーク可到達性情報を交換することです。このネットワーク可到達性情報はトラフィックはこれらがネットワークでつなぐ範囲へのトランジットがそうしなければならないという自律システム(ASのもの)の情報を含んでいます。 この情報は、ルーティング輪余計なものを取り除かれるかもしれなくて、ASレベルにおける政策決定が励行されるかもしれないASの接続性のグラフを作図するために十分です。
BGP runs over a reliable transport level 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.
信頼できる輸送レベルの上のBGP走行は議定書を作ります。 これは明白なアップデート断片化、「再-トランスミッション」、承認、および配列を実装する必要性を排除します。 トランスポート・プロトコルによって使用されるどんな認証体系もBGPの自身の認証機構に加えて使用されるかもしれません。
The initial BGP implementation is based on TCP [4], however any reliable transport may be used. A message passing protocol such as VMTP [5] might be more natural for BGP. TCP will be used, however, since it is present in virtually all commercial routers and hosts. In the following descriptions the phrase "transport protocol connection" can be understood to refer to a TCP connection. BGP uses TCP port 179 for establishing its connections.
初期のBGP実装はTCP[4]に基づいていて、しかしながら、どんな信頼できる輸送も使用されるかもしれません。 BGPには、VMTP[5]などのメッセージ・パッシングプロトコルは、より当然であるかもしれません。 それがほとんどすべての商業ルータとホストに存在しているので、しかしながら、TCPは使用されるでしょう。 以下の記述では、TCP接続について言及するのを「輸送プロトコル接続」という句を理解できます。 BGPは、接続を確立するのにTCPポート179を使用します。
Lougheed & Rekhter [Page 1] RFC 1105 BGP June 1989
ロッキードとRekhter[1ページ]RFC1105BGP1989年6月
2. Summary of Operation
2. 操作の概要
Two hosts 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. 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 optionally closed.
2人のホストがお互いの間の輸送プロトコル接続を形成します。 彼らは接続パラメタを開いて、確認するメッセージを交換します。 初期のデータフローは全体の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 gateway in another autonomous system. The implications and applications of this architecture are for further study.
ボーダ・ゲイトウェイ・プロトコルを実行するホストはルータである必要はありません。 非ルーティングホストはEGPか内部のルーティング・プロトコルでさえルーティング情報をルータと交換できるでしょう。 そして、その非ルーティングホストは、別の自律システムの境界ゲートウェイとルーティング情報を交換するのにBGPを使用できました。 さらなる研究にはこのアーキテクチャの含意と利用があります。
If a particular AS has more than one BGP gateway, then all these gateways should have a consistent view of routing. A consistent view of the interior routes of the autonomous system is provided by the intra-AS routing protocol. A consistent view of the routes exterior to the AS may be provided in a variety of ways. One way is to use the BGP protocol to exchange routing information between the BGP gateways within a single AS. In this case, in order to maintain consist routing information, these gateways MUST have direct BGP sessions with each other (the BGP sessions should form a complete graph). Note that this requirement does not imply that all BGP gateways within a single AS must have direct links to each other; other methods may be used to ensure consistent routing information.
特定のASに1BGP門以上があるなら、これらのすべてのゲートウェイには、ルーティングの一貫した視点があるはずです。 イントラ-ASルーティング・プロトコルは自律システムの内部のルートの一貫した意見を提供します。 さまざまな方法でASへの外のルートの一貫した意見を提供するかもしれません。 1つの方法は独身のASの中のBGPゲートウェイの間でルーティング情報を交換するのにBGPプロトコルを使用することです。 この場合、情報を発送しながら成るように主張するには、これらのゲートウェイは互いとのダイレクトBGPセッションを過さなければなりません(BGPセッションは完全なグラフを形成するべきです)。 この要件が、独身のASの中のすべてのBGPゲートウェイが互いに直リンクを持たなければならないのを含意しないことに注意してください。 他のメソッドは、一貫したルーティング情報を確実にするのに使用されるかもしれません。
3. Message Formats
3. メッセージ・フォーマット
This section describes message formats and actions to be taken when errors are detected while processing these messages.
このセクションは、これらのメッセージを処理している間誤りを検出するとき、取るためにメッセージ・フォーマットと動作について説明します。
Messages are sent over a reliable transport protocol connection. A message is processed after it is entirely received. The maximum message size is 1024 bytes. 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 8 bytes.
頼もしい輸送プロトコル接続の上にメッセージを送ります。 それを完全に受け取った後にメッセージを処理します。 最大のメッセージサイズは1024バイトです。 すべての実装が、この最大のメッセージがサイズであるとサポートするのに必要です。 送られるかもしれない中で最も小さいメッセージはデータ部も、または8バイトなしで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. This information is passed to other BGP peers before being deleted from the system.
接続が持っているトランスポート・プロトコルをある「BGP接続は閉じられること」が意味する句が閉じました、そして、そのBGP接続へのすべてのリソースが「反-割り当て」られました。 リモート同輩に関連している経路指定テーブルエントリーは無効であることが示されます。 システムから削除される前にこの情報は他のBGP同輩に渡されます。
Lougheed & Rekhter [Page 2] RFC 1105 BGP June 1989
ロッキードとRekhter[2ページ]RFC1105BGP1989年6月
3.1 Message Header Format
3.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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Type | Hold Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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: 16 bits
マーカー: 16ビット
The Marker field is 16 bits of all ones. This field is used to
mark the start of a message. If the first two bytes of a message
are not all ones then we have a synchronization error and the BGP
connection should be closed after sending a notification message
with opcode 5 (connection not synchronized). No notification data
is sent.
Marker分野はすべてのものの16ビットです。 この分野は、メッセージの始まりを示すのに使用されます。 メッセージの最初の2バイトがすべてものであるというわけではないなら、私たちには、同期誤りがあります、そして、通知メッセージを送った後に、BGP接続はopcode5で閉店するべきです(接続は連動しませんでした)。 通知データを全く送りません。
Length: 16 bits
長さ: 16ビット
The Length field is 16 bits. It is the total length of the
message, incluluding header, in bytes. If an illegal length is
encountered (more than 1024 bytes or less than 8 bytes), a
notification message with opcode 6 (bad message length) and two
data bytes of the bad length should be sent and the BGP connection
closed.
Length分野は16ビットです。 バイトでヘッダーをincluludingして、それはメッセージの全長です。 不法な長さに遭遇するなら(1024バイト以上か8バイト未満)、opcode6(悪いメッセージ長)がある通知メッセージと悪い長さの2データ・バイトを送るべきでした、そして、BGP接続は閉じました。
Version: 8 bits
バージョン: 8ビット
The Version field is 8 bits of protocol version number. The
current BGP version number is 1. If a bad version number is
found, a notification message with opcode 8 (bad version number)
should be sent and the BGP connection closed. The bad version
number should be included in one byte of notification data.
バージョン分野はプロトコルバージョン番号の8ビットです。 現在のBGPバージョン番号は1です。 悪いバージョン番号を見つけるなら、opcode8(悪いバージョン番号)がある通知メッセージを送るべきでした、そして、BGP接続は閉じました。 悪いバージョン番号は1バイトの通知データに含まれるべきです。
Type: 8 bits
以下をタイプしてください。 8ビット
The Type field is 8 bits of message type code. The following type
codes are defined:
Type分野はメッセージタイプコードの8ビットです。 以下のタイプコードは定義されます:
Lougheed & Rekhter [Page 3] RFC 1105 BGP June 1989
ロッキードとRekhter[3ページ]RFC1105BGP1989年6月
1 - OPEN
2 - UPDATE
3 - NOTIFICATION
4 - KEEPALIVE
5 - OPEN CONFIRM
1--開いている通知4(KEEPALIVE5)が確認する開いている2(アップデート3)
If an unrecognized type value is found, a notification message
with opcode 7 (bad type code) and data consisting of the byte of
type field in question should be sent and the BGP connection
closed.
認識されていないタイプ値を見つけるなら、opcode7(悪いタイプコード)とデータが問題のタイプ分野のバイトから成っている通知メッセージを送るべきでした、そして、BGP接続は閉じました。
Hold Timer: 16 bits.
タイマを持ってください: 16ビット。
This field contains the number of seconds that may elapse since
receiving a BGP KEEPALIVE or BGP UPDATE message from our BGP peer
before we declare an error and close the BGP connection.
この分野は私たちが誤りを宣言して、BGP接続を終える前に私たちのBGP同輩からBGP KEEPALIVEかBGP UPDATEメッセージを受け取って以来経過するかもしれない秒数を含んでいます。
3.2 OPEN Message Format
3.2 開いているメッセージ・フォーマット
After a transport protocol connection is established, the first message sent by either side is an OPEN message. If the OPEN message is acceptable, an OPEN CONFIRM message confirming the OPEN is sent back. Once the OPEN is confirmed, UPDATE, KEEPALIVE, and NOTIFICATION messages may be exchanged.
輸送プロトコル接続が確立された後に、どちらの側によっても送られた最初のメッセージはオープンメッセージです。 オープンメッセージが許容できるなら、オープンを確認するOPEN CONFIRMメッセージは返送されます。 いったんオープンを確認すると、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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| My Autonomous System | Link Type | Auth. Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Authentication Data |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 私の自律システム| リンク型| Auth。 コード| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | 認証データ| | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
My Autonomous System: 16 bits
私の自律システム: 16ビット
This field is our 16 bit autonomous system number. If there is a
problem with this field, a notification message with opcode 9
(invalid AS field) should be sent and the BGP connection closed.
No notification data is sent.
この分野は私たちの16ビットの自律システム番号です。 この分野に関する問題があれば、opcode9(無効のAS分野)がある通知メッセージを送るべきでした、そして、BGP接続は閉じました。 通知データを全く送りません。
Link Type: 8 bits
タイプをリンクしてください: 8ビット
The Link Type field is a single octet containing one of the
Link Type分野は1つを含むただ一つの八重奏です。
Lougheed & Rekhter [Page 4] RFC 1105 BGP June 1989
ロッキードとRekhter[4ページ]RFC1105BGP1989年6月
following codes defining our position in the AS graph relative to
our peer.
ASで私たちの立場を定義する次のコードが私たちの同輩に比例してグラフ化します。
0 - INTERNAL
1 - UP
2 - DOWN
3 - H-LINK
0対2(内部の1)--下に3--H-リンク
UP indicates the peer is higher in the AS hierarchy, DOWN
indicates lower, and H-LINK indicates at the same level. INTERNAL
indicates that the peer is another BGP speaking host in our
autonomous system. INTERNAL links are used to keep AS routing
information consistent with an AS with multiple border gateways.
If the Link Type field is unacceptable, a notification message
with opcode 1 (link type error in open) and data consisting of the
expected link type should be sent and the BGP connection closed.
The acceptable values for the Link Type fields of two BGP peers
are discussed below.
UPが、AS階層構造で同輩が、より高いのを示すのをDOWNは、より低く示して、H-LINKは、同じレベルで示します。 INTERNALは、同輩が私たちの自律システムの別のBGPの話すホストであることを示します。 INTERNALリンクは、複数の境界ゲートウェイでASと一致しているようにASルーティング情報を保つのに使用されます。 Link Type分野が容認できないなら、opcode1(戸外のリンク型誤り)とデータが予想されたリンク型から成っている通知メッセージを送るべきでした、そして、BGP接続は閉じました。 以下で2人のBGP同輩のLink Type分野への許容値について議論します。
Authentication Code: 8 bits
認証コード: 8ビット
The Authentication Code field is an octet whose value describes
the authentication mechanism being used. A value of zero
indicates no BGP authentication. Note that a separate
authentication mechanism may be used in establishing the transport
level connection. If the authentication code is not recognized, a
notification message with opcode 2 (unknown authentication code)
and no data is sent and the BGP connection is closed.
Authentication Code分野は値が使用される認証機構について説明する八重奏です。 ゼロの値はBGP認証を全く示しません。 別々の認証機構が輸送レベル接続を確立する際に使用されるかもしれないことに注意してください。 認証子を認識しないなら、opcode2(未知の認証コード)がある通知メッセージを送りますが、どんなデータも送りません、そして、BGP接続は閉じます。
Authentication Data: variable length
認証データ: 可変長
The Authentication Data field is a variable length field
containing authentication data. If the value of Authentication
Code field is zero, the Authentication Data field has zero length.
If authentication fails, a notification message with opcode 3
(authentication failure) and no data is sent and the BGP
connection is closed.
Authentication Data分野は認証データを含む可変長フィールドです。 Authentication Code分野の値がゼロであるなら、Authentication Data分野には、ゼロ・レングスがあります。 認証が失敗するなら、opcode3(認証失敗)がある通知メッセージを送りますが、どんなデータも送りません、そして、BGP接続は閉じます。
3.3 OPEN CONFIRM Message Format
開いている3.3はメッセージ・フォーマットを確認します。
An OPEN CONFIRM message is sent after receiving an OPEN message. This completes the BGP connection setup. UPDATE, NOTIFICATION, and KEEPALIVE messages may now be exchanged.
オープンメッセージを受け取った後に、OPEN CONFIRMメッセージを送ります。 これはBGP接続設定を終了します。 現在、UPDATE、NOTIFICATION、およびKEEPALIVEメッセージを交換するかもしれません。
An OPEN CONFIRM message consists of a BGP header with an OPEN CONFIRM type code. There is no data in an OPEN CONFIRM message.
OPEN CONFIRMメッセージはOPEN CONFIRMタイプコードでBGPヘッダーから成ります。 OPEN CONFIRMメッセージにはデータが全くありません。
Lougheed & Rekhter [Page 5] RFC 1105 BGP June 1989
ロッキードとRekhter[5ページ]RFC1105BGP1989年6月
3.4 UPDATE Message Format
3.4 アップデートメッセージ・フォーマット
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 the inter-AS routing.
UPDATEメッセージは、BGP同輩の間にルーティング情報を移すのに使用されます。 様々な自律システムの関係について説明するグラフを作図するのにUPDATEパケットの情報を使用できます。議論するために規則を適用することによって、ルーティング情報輪とある他の例外は、相互ASルーティングから検出されて、取り外されるかもしれません。
Whenever an error in a UPDATE message is detected, a notification message is sent with opcode 4 (bad update), a two byte subcode describing the nature of the problem, and a data field consisting of as much of the UPDATE message data portion as possible. UPDATE messages have the following format:
UPDATEメッセージにおける誤りが検出されるときはいつも、問題の性格について説明する2バイトの部分符号、およびopcode4(悪いアップデート)、できるだけ多くのUPDATEメッセージデータ部から成るデータ・フィールドと共に通知メッセージを送ります。 UPDATEメッセージには、以下の形式があります:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Gateway |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AS count | Direction | AS Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| repeat (Direction, AS Number) pairs AS count times |
/ /
/ /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Net Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Metric | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| repeat (Network, Metric) pairs Net Count times |
/ /
/ /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ゲートウェイ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ASは数えます。| 方向| 数として| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 反復(方向、AS Number)組ASは回を数えます。| / / / / | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ネットのカウント| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ネットワーク| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | メートル法| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 反復(ネットワーク、Metric)はネットCount回数を対にします。| / / / / | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Gateway: 32 bits.
ゲートウェイ: 32ビット。
The Gateway field is the address of a gateway that has routes to
the Internet networks listed in the rest of the UPDATE message.
This gateway MUST belong to the same AS as the BGP peer who
advertises it. If there is a problem with the gateway field, a
notification message with subcode 6 (invalid gateway field) is
sent.
ゲートウェイ分野はUPDATEメッセージの残りで記載されたインターネット網にルートを持っているゲートウェイのアドレスです。 このゲートウェイはそれの広告を出すBGP同輩と同じASに属さなければなりません。 ゲートウェイ分野に関する問題があれば、部分符号6(無効のゲートウェイ分野)がある通知メッセージを送ります。
Lougheed & Rekhter [Page 6] RFC 1105 BGP June 1989
ロッキードとRekhter[6ページ]RFC1105BGP1989年6月
AS count: 8 bits.
ASは数えます: 8ビット。
This field is the count of Direction and AS Number pairs in this
UPDATE message. If an incorrect AS count field is detected,
subcode 1 (invalid AS count) is specified in the notification
message.
この分野はこのUPDATEメッセージのDirectionとAS Number組のカウントです。 不正確なASカウント分野が検出されるなら、部分符号1(無効のASは数えます)は通知メッセージで指定されます。
Direction: 8 bits
方向: 8ビット
The Direction field is an octet containing the direction taken by
the routing information when exiting the AS defined by the
succeeding AS Number field. The following values are defined.
Direction分野は続くAS Number分野によって定義されたASを出るときルーティング情報によって取られた方向を含む八重奏です。 以下の値は定義されます。
1 - UP (went up a link in the graph)
2 - DOWN (went down a link in the graph)
3 - H_LINK (horizontal link in the graph)
4 - EGP_LINK (EGP derived information)
5 - INCOMPLETE (incomplete information)
1--UP(グラフをリンクを上がった)2--DOWN(グラフをリンクを下った)3--H_LINK(グラフによる水平なリンク)4--EGP_LINK(EGPは情報を引き出した)5--INCOMPLETE(不完全情報)
There is a special provision to pass exterior learned (non-BGP)
routes over BGP. If an EGP learned route is passed over BGP, then
the Direction field is set to EGP-LINK and the AS Number field is
set to the AS number of the EGP peer that advertised this route.
All other exterior-learned routes (non-BGP and non-EGP) may be
passed by setting AS Number field to zero and Direction field to
INCOMPLETE. If the direction code is not recognized, a
notification message with subcode 2 (invalid direction code) is
sent.
外の学術的な(非BGPの)ルートをBGPの上に渡すために、特別条項があります。 EGPの学術的ルートがBGPの上に渡されるなら、Direction分野はEGP-LINKに設定されます、そして、AS Number分野はこのルートの広告を出したEGP同輩のAS番号に設定されます。 他のすべての外に学術的なルート(非BGPと非EGP)がAS Numberがゼロとしてさばいて、DirectionがINCOMPLETEとしてさばく設定によって渡されるかもしれません。 方向コードを認識しないなら、部分符号2(無効の方向コード)がある通知メッセージを送ります。
AS Number: 16 bits
数として: 16ビット
This field is the AS number that transmitted the routing
information. If there is a problem with this AS number, a
notification message with subcode 3 (invalid autonomous system) is
sent.
この分野はルーティング情報を伝えたAS番号です。 このAS番号に関する問題があれば、部分符号3(無効の自律システム)がある通知メッセージを送ります。
Net Count: 16 bits.
ネットのカウント: 16ビット。
The Net Count field is the number of Metric and Network field
pairs which follow this field. If there is a problem with this
field, a notification with subcode 7 (invalid net count field) is
sent.
ネットCount分野は、Metricの数とこの野原の後をつけるNetwork分野組です。 この分野に関する問題があれば、部分符号7(無効のネットのカウント分野)による通知を送ります。
Network: 32 bits
以下をネットワークでつないでください。 32ビット
The Network field is four bytes of Internet network number. If
there is a problem with the network field, a notification message
with subcode 8 (invalid network field) is sent.
Network分野は4バイトのインターネットネットワーク・ナンバーです。 ネットワーク分野に関する問題があれば、部分符号8(無効のネットワーク分野)がある通知メッセージを送ります。
Lougheed & Rekhter [Page 7] RFC 1105 BGP June 1989
ロッキードとRekhter[7ページ]RFC1105BGP1989年6月
Metric: 16 bits
メートル法: 16ビット
The Metric field is 16 bits of an unspecified metric. BGP metrics
are comparable ONLY if routes have exactly the same AS path. A
metric of all ones indicates the network is unreachable. In all
other cases the metric field is MEANINGLESS and MUST BE IGNORED.
There are no illegal metric values.
Metric分野が16ビットである、不特定である、メートル法です。 ルートにまさに同じAS経路があるだけであるなら、BGP測定基準は匹敵しています。 Aメートル法、すべてでは、人は、ネットワークが手が届かないのを示します。 他のすべての場合では、メートル法の分野は、MEANINGLESSとMUST BE IGNOREDです。 どんな不法なメートル法の数値もありません。
3.5 NOTIFICATION Message Format
3.5 通知メッセージ・フォーマット
NOTIFICATION messages are sent when an error condition is detected. The BGP connection is closed shortly after sending the notification message.
エラー条件を検出するとき、NOTIFICATIONメッセージを送ります。 通知メッセージを送ったすぐ後に、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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opcode | Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Opcode| データ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Opcode: 16 bits
Opcode: 16ビット
The Opcode field describes the type of NOTIFICATION. The
following opcodes have been defined.
Opcode分野はNOTIFICATIONのタイプについて説明します。 以下のopcodesは定義されました。
1 (*) - link type error in open. Data is one byte of proper
link type.
2 (*) - unknown authentication code. No data.
3 (*) - authentication failure. No data.
4 - update error. See below for data description.
5 (*) - connection out of sync. No data.
6 (*) - invalid message length. Data is two bytes of
bad length.
7 (*) - invalid message type. Data is one byte of bad
message type.
8 (*) - invalid version number. Data is one byte of
bad version.
9 (*) - invalid AS field in OPEN. No data.
10 (*) - BGP Cease. No data.
1(*)--戸外でタイプ誤りをリンクしてください。 データは適切なリンク型の1バイトです。 2 (*)--未知の認証コード。 データがありません。 3 (*)--認証失敗。 データがありません。 4--誤りをアップデートしてください。 データ記述に関して以下を見てください。 5 (*)--接続同期していません。 データがありません。 6 (*)--無効のメッセージ長。 データは2バイトの悪い長さです。 7 (*)--無効のメッセージタイプ。 データは悪いメッセージタイプの1バイトです。 8 (*)--無効のバージョン番号。 データは1バイトの悪いバージョンです。 9 (*)--オープンにおける無効のAS分野。 データがありません。 10 (*)--BGPはやみます。 データがありません。
The starred opcodes in the list above are considered fatal errors
and cause transport connection termination.
上記のリストの主演されたopcodesは致命的な誤りと原因輸送接続終了であると考えられます。
The update error (opcode 4) has as data 16 bits of subcode
followed by the last UPDATE message in question. After the
subcode comes as much of the data portion of the UPDATE in
アップデート誤り(opcode4)には、データとして問題の最後のUPDATEメッセージがあとに続いた部分符号の16ビットがあります。 部分符号がUPDATEのデータ部の多くとして中に来た後に
Lougheed & Rekhter [Page 8] RFC 1105 BGP June 1989
ロッキードとRekhter[8ページ]RFC1105BGP1989年6月
question as possible. The following subcodes are defined:
可能であるとしての問題。 以下の部分符号は定義されます:
1 - invalid AS count
2 - invalid direction code
3 - invalid autonomous system
4 - EGP_LINK or INCOMPLETE_LINK link type at other than
the end of the AS path list
5 - routing loop
6 - invalid gateway field
7 - invalid Net Count field
8 - invalid network field
無効のASが2を数えるというAS経路リスト5--ルーティング輪6--無効のゲートウェイ分野7--無効のネットCount分野8--無効のネットワーク分野の端を除いて、無効の方向コード3--無効の自律システム4--EGP_LINKかINCOMPLETE_LINKがタイプをリンクする1
Data: variable
データ: 変数
The Data field contains zero or more bytes of data to be used in
diagnosing the reason for the NOTIFICATION. The contents of the
Data field depend upon the opcode. See the opcode descriptions
above for more details.
Data分野はゼロか、より多くのバイトのNOTIFICATIONの理由を診断する際に使用されるべきデータを含んでいます。 Data分野の内容はopcodeによります。 その他の詳細において、opcode記述が上であることを見てください。
3.6 KEEPALIVE Message Format
3.6 KEEPALIVEメッセージ・フォーマット
BGP does not use any transport protocol based keepalive mechanism to determine if peers are reachable. Instead KEEPALIVE messages are exchanged between peers often enough as not to cause the hold time (as advertised in the BGP header) to expire. A reasonable minimum frequency of KEEPALIVE exchange would be one third of the Hold Time interval.
BGPは、同輩が届くかどうか決定するのにどんなトランスポート・プロトコルに基づいているkeepaliveメカニズムも使用しません。 代わりに、保持時間(BGPヘッダーの広告に掲載されているように)が期限が切れることを引き起こさないで、同輩の間でKEEPALIVEメッセージをしばしば十分交換します。 KEEPALIVE交換の妥当な最小の頻度はHold Time間隔の1/3でしょう。
As soon as the Hold Time associated with BGP peer has expired, the BGP connection is closed and BGP deallocates all resources associated with this peer.
BGP同輩に関連しているHold Timeが期限が切れるとすぐに、BGP接続は閉じられます、そして、この同輩に関連しているすべてのリソースがBGP deallocatesが閉じられます。
The KEEPALIVE message is a BGP header without any data.
KEEPALIVEメッセージは少しもデータがなければBGPヘッダーです。
4. BGP Finite State machine.
4. BGP Finite州マシン。
This section specifies BGP operation in terms of a Finite State Machine (FSM). Following is a brief summary and overview of BGP operations by state as determined by this FSM. A condensed version of the BGP FSM is found in Appendix 1.
このセクションはFinite州Machine(FSM)に関してBGP操作を指定します。 以下に、このFSMによって決定されるように状態によるBGP操作の簡潔な概要と概要があります。 BGP FSMの縮約版はAppendix1で見つけられます。
Initially BGP is in the BGP_Idle state.
初めは、BGPがBGP_Idle状態にあります。
BGP_Idle state:
BGP_Idle州:
In this state BGP refuses all incoming BGP connections. No
resources are allocated to the BGP neighbor. In response to the
Start event (initiated by either system or operator) the local
この状態では、BGPはすべての入って来るBGP接続を拒否します。 リソースを全くBGP隣人に割り当てません。 Startイベント(システムかオペレータのどちらかによって開始される)に対応した地方
Lougheed & Rekhter [Page 9] RFC 1105 BGP June 1989
ロッキードとRekhter[9ページ]RFC1105BGP1989年6月
system initializes all BGP resources and changes its state to
BGP_Active.
システムは、すべてのBGPリソースを初期化して、状態をBGP_Activeに変えます。
BGP_Active state:
BGP_Active州:
In this state BGP is trying to acquire a BGP neighbor by opening a
transport protocol connection. If the transport protocol open
fails (for example, retransmission timeout), BGP stays in the
BGP_Active state.
この状態では、BGPは、輸送プロトコル接続を開くことによって、BGP隣人を取得しようとしています。 トランスポート・プロトコル戸外が(例えば、再送タイムアウト)に失敗するなら、BGPはBGP_Active状態にいます。
Otherwise, the local system sends an OPEN message to its peer,
and changes its state to BGP_OpenSent. Since the hold time of the
peer is still undetermined, the hold time is initialized to some
large value.
さもなければ、ローカルシステムは、オープンメッセージを同輩に送って、状態をBGP_OpenSentに変えます。 同輩の保持時間がまだ非決定しているので、保持時間は何らかの大きい値に初期化されます。
In response to the Stop event (initiated by either system or
operator) the local system releases all BGP resources and changes
its state to BGP_Idle.
Stopイベント(システムかオペレータのどちらかによって開始される)に対応して、ローカルシステムは、すべてのBGPリソースを発表して、状態をBGP_Idleに変えます。
BGP_OpenSent state:
BGP_OpenSent州:
In this state BGP waits for an OPEN message from its peer. When
an OPEN message is received, all fields are checked for
correctness. If the initial BGP header checking detects an error,
BGP deallocates all resources associated with this peer and
returns to the BGP_Active state. Otherwise, the Link Type,
Authentication Code, and Authentication Data fields are checked
for correctness.
この状態では、BGPは同輩からのオープンメッセージを待っています。 オープンメッセージが受信されているとき、すべての分野が正当性がないかどうかチェックされます。 初期のBGPヘッダーの照合が誤り、すべてのリソースがこの同輩に関連づけたBGP deallocatesを検出して、BGP_Active状態に戻るなら。 さもなければ、Link Type、Authentication Code、およびAuthentication Data分野は正当性がないかどうかチェックされます。
If the link type is incorrect, a NOTIFICATION message with opcode
1 (link type error in open) is sent. The following combination of
link type fields are correct; all other combinations are invalid.
リンク型が不正確であるなら、opcode1(戸外のリンク型誤り)があるNOTIFICATIONメッセージを送ります。 リンク型分野の以下の組み合わせは正しいです。 他のすべての組み合わせが無効です。
Our view Peer view
UP DOWN
DOWN UP
INTERNAL INTERNAL
H-LINK H-LINK
私たちの視点Peer視点UP DOWN DOWN UP INTERNAL INTERNAL H-LINK H-LINK
If the link between two peers is INTERNAL, then AS number of both
peers must be the same. Otherwise, a NOTIFICATION message with
opcode 1 (link type error in open) is sent.
2人の同輩の間のリンクがINTERNALであるなら、両方の同輩のAS番号は同じであるに違いありません。 さもなければ、opcode1(戸外のリンク型誤り)があるNOTIFICATIONメッセージを送ります。
If both peers have the same AS number and the link type between
these peers is not INTERNAL, then a NOTIFICATION message with
opcode 1 (link type error in open) is sent.
両方の同輩には同じAS番号があって、これらの同輩の間のリンク型がINTERNALでないなら、opcode1(戸外のリンク型誤り)があるNOTIFICATIONメッセージを送ります。
If the value of the Authentication Code field is zero, any
Authentication Code分野の値がいくらかゼロであるなら
Lougheed & Rekhter [Page 10] RFC 1105 BGP June 1989
ロッキードとRekhter[10ページ]RFC1105BGP1989年6月
information in the Authentication Data field (if present) is
ignored. If the Authentication Code field is non-zero it is
checked for known authentication codes. If authentication code is
unknown, then the BGP NOTIFICATION message with opcode 2 (unknown
authentication code) is sent.
Authentication Data分野(存在しているなら)の情報は無視されます。 Authentication Code分野が非ゼロであるなら、それは知られている認証子がないかどうかチェックされます。 認証コードが未知であるなら、opcode2(未知の認証コード)があるBGP NOTIFICATIONメッセージを送ります。
If the Authentication Code value is non-zero, then the
corresponding authentication procedure is invoked. The default
values are a zero Authentication Code and no Authentication Data.
Authentication Code値が非ゼロであるなら、対応する認証手順は呼び出されます。 デフォルト値は、Authentication CodeがなくてまたAuthentication Dataではありません。
If any of the above tests detect an error, the local system closes
the BGP connection and changes its state to BGP_Idle.
上のテストのどれかが誤りを検出するなら、ローカルシステムは、BGP接続を終えて、状態をBGP_Idleに変えます。
If there are no errors in the BGP OPEN message, BGP sends an OPEN
CONFIRM message and goes into the BGP_OpenConfirm state. At this
point the hold timer which was originally set to some arbitrary
large value (see above) is replaced with the value indicated in
the OPEN message.
BGP OPENメッセージに誤りが全くなければ、BGPはOPEN CONFIRMメッセージを送って、BGP_OpenConfirm状態に入ります。 ここに、元々何らかの任意の大きい値(上を見る)に設定された保持タイマをオープンメッセージで示される値に取り替えます。
If disconnect notification is received from the underlying
transport protocol or if the hold time expires, the local system
closes the BGP connection and changes its state to BGP_Idle.
基本的なトランスポート・プロトコルから分離通知を受け取るか、または保持時間が期限が切れるなら、ローカルシステムは、BGP接続を終えて、状態をBGP_Idleに変えます。
BGP_OpenConfirm state:
BGP_OpenConfirm州:
In this state BGP waits for an OPEN CONFIRM message. As soon as
this message is received, BGP changes its state to
BGP_Established. If the hold timer expires before an OPEN CONFIRM
message is received, the local system closes the BGP connection
and changes its state to BGP_Idle.
この状態では、BGPはOPEN CONFIRMメッセージを待っています。 このメッセージが受信されているとすぐに、BGPは状態をBGP_Establishedに変えます。 OPEN CONFIRMメッセージが受信されている前に保持タイマが期限が切れるなら、ローカルシステムは、BGP接続を終えて、状態をBGP_Idleに変えます。
BGP_Established state:
BGP_Established州:
In the BGP_Established state BGP can exchange UPDATE,
NOTIFICATION, and KEEPALIVE messages with its peer.
BGP_Established状態では、BGPは同輩と共にUPDATE、NOTIFICATION、およびKEEPALIVEメッセージを交換できます。
If disconnect notification is received from the underlying
transport protocol or if the hold time expires, the local system
closes the BGP connection and changes its state to BGP_Idle.
基本的なトランスポート・プロトコルから分離通知を受け取るか、または保持時間が期限が切れるなら、ローカルシステムは、BGP接続を終えて、状態をBGP_Idleに変えます。
In response to the Stop event initiated by either the system or
operator, the local system sends a NOTIFICATION message with
opcode 10 (BGP Cease), closes the BGP connection, and changes its
state to BGP_Idle.
システムかオペレータによって開始されたStopイベントに対応して、ローカルシステムは、BGP_Idleにopcode10(BGP Cease)でNOTIFICATIONメッセージを送って、BGP接続を終えて、状態を変えます。
Lougheed & Rekhter [Page 11] RFC 1105 BGP June 1989
ロッキードとRekhter[11ページ]RFC1105BGP1989年6月
5. UPDATE Message Handling
5. アップデートメッセージハンドリング
A BGP UPDATE message may be received only in the BGP_Established state. When a BGP UPDATE message is received, each field is checked for validity. When a NOTIFICATION message is sent regarding an UPDATE, the opcode is always 4 (update error), the subcode depends on the type of error, and the rest of the data field is as much as possible of the data portion of the UPDATE that caused the error.
BGP_Established状態だけにBGP UPDATEメッセージを受け取るかもしれません。 BGP UPDATEメッセージが受信されているとき、各分野は正当性がないかどうかチェックされます。 UPDATEに関してNOTIFICATIONメッセージを送るとき、いつもopcodeは4(誤りをアップデートする)です、そして、部分符号を誤りのタイプに頼っています、そして、データ・フィールドの残りはUPDATEのデータ部では、できるだけ、それが誤りを引き起こしたということです。
If the Gateway field is incorrect, a BGP NOTIFICATION message is sent with subcode 6 (invalid gateway field). All information in this UPDATE message is discarded.
ゲートウェイ分野が不正確であるなら、部分符号6(無効のゲートウェイ分野)と共にBGP NOTIFICATIONメッセージを送ります。 このUPDATEメッセージのすべての情報が捨てられます。
If the AS Count field is less than or equal to zero, a BGP NOTIFICATION is sent with subcode 1 (invalid AS count). Otherwise, the complete AS path is extracted and checked as described below.
AS Count分野がゼロ以下であるなら、部分符号1と共にBGP NOTIFICATIONを送ります(無効のASは数えます)。 さもなければ、完全なAS経路は、以下で説明されるように抽出されて、チェックされます。
If one of the Direction fields in the AS route list is not defined, a BGP NOTIFICATION message is with subcode 2 (invalid direction code).
ASルートリストのDirection分野の1つが定義されないなら、BGP NOTIFICATIONメッセージが部分符号2(無効の方向コード)と共にあります。
If one of the AS Number fields in the AS route list is incorrect, a BGP NOTIFICATION message is sent with subcode 3 (invalid autonomous system).
ASルートリストのAS Number分野の1つが不正確であるなら、部分符号3(無効の自律システム)と共にBGP NOTIFICATIONメッセージを送ります。
If either a EGP_LINK or a INCOMPLETE_LINK link type occurs at other than the end of the AS path, a BGP NOTIFICATION message is sent with subcode 4 (EGP_LINK or INCOMPLETE_LINK link type at other than the end of the AS path list).
AS経路の端を除いて、LINKリンク型が起こるEGP_LINKかINCOMPLETE_のどちらかであるなら、部分符号4(AS経路リストの終わりを除いて、LINKがタイプをリンクするEGP_LINKかINCOMPLETE_)と共にBGP NOTIFICATIONメッセージを送ります。
If none of the above tests failed, the full AS route is checked for AS loops.
上のテストのいずれも失敗しなかったなら、完全なASルートはAS輪がないかどうかチェックされます。
AS loop detection is done by scanning the full AS route and checking that each AS in this route occurs only once. If an AS loop is detected, a BGP NOTIFICATION message is sent with subcode 5 (routing loop).
完全なASルートをスキャンして、このルートによる各ASが一度だけ起こるのをチェックすることによって、AS輪の検出をします。 AS輪を検出するなら、部分符号5(ルーティング輪)と共にBGP NOTIFICATIONメッセージを送ります。
If any of the above errors are detected, no further processing is done. Otherwise, the complete AS path is correct and the rest of the UPDATE message is processed.
上の誤りのどれかを検出するなら、どんなより遠い処理もしません。 さもなければ、完全なAS経路は正しいです、そして、UPDATEメッセージの残りは処理されます。
If the Net Count field is incorrect, a BGP NOTIFICATION message is sent with subcode 7 (invalid Net Count field).
ネットCount分野が不正確であるなら、部分符号7(Countがさばく無効のネット)と共にBGP NOTIFICATIONメッセージを送ります。
Each network and metric pair listed in the BGP UPDATE message is checked for a valid network number. If the Network field is incorrect, a BGP Notification message is sent with subcode 8 (invalid network field). No checking is done on the metric field. It is up
BGP UPDATEメッセージに記載されたそれぞれのネットワークとメートル法の組は有効なネットワーク・ナンバーがないかどうかチェックされます。 Network分野が不正確であるなら、部分符号8(無効のネットワーク分野)と共にBGP Notificationメッセージを送ります。 メートル法のフィールドではチェックしないこと。 それは上がっています。
Lougheed & Rekhter [Page 12] RFC 1105 BGP June 1989
ロッキードとRekhter[12ページ]RFC1105BGP1989年6月
to a particular implementation to decide whether to continue processing or terminate it upon the first incorrect network.
最初の不正確なネットワークで処理し続けているか、またはそれを終えるかを決める特定の実装に。
If the network, its complete AS path, and the gateway are correct, then the route is compared with other routes to the same network. If the new route is better than the current one, then it is flooded to other BGP peers as follows:
ネットワーク、完全なAS経路、およびゲートウェイが正しいなら、ルートは同じネットワークへの他のルートにたとえられます。 新しいルートが現在のものより良いなら、それは以下の他のBGP同輩へあふれます:
- If the BGP UPDATE was received over the INTERNAL link, it is not
propagated over any other INTERNAL link. This restriction is
due to the fact that all BGP gateways within a single AS
form a completely connected graph (see above).
- INTERNALリンクの上にBGP UPDATEを受け取ったなら、いかなる他のINTERNALリンクの上にもそれを伝播しません。 この制限は独身のASの中のすべてのBGPゲートウェイが完全に接続されたグラフを形成するという(上を見てください)事実のためです。
- Before sending a BGP UPDATE message over the non-INTERNAL links,
check the AS path to insure that doing so would not cause a
routing loop. The BGP UPDATE message is then propagated (subject
to the local policy restrictions) over any of the non-INTERNAL
link of a routing loop would not result.
- 非INTERNALリンクの上にBGP UPDATEメッセージを送る前に、AS経路をチェックして、そうするのがルーティング輪を引き起こさないのを保障してください。 BGP UPDATEメッセージは次に、ルーティング輪のいずれも上で非INTERNALについて伝播された(ローカルの方針制限を条件とした)リンクが結果として生じないだろうということです。
- If the BGP UPDATE message is propagated over a non-INTERNAL link,
then the current AS number and link type of the link over which
it is going to be propagated is prepended to the full AS path
and the AS count field is incremented by 1. If the BGP UPDATE
message is propagated over an INTERNAL link, then the full AS
path passed unmodified and the AS count stays the same. The
Gateway field is replaced with the sender's own address.
- BGP UPDATEメッセージが非INTERNALリンクの上に伝播されるなら、それが伝播されるリンクの現在のAS番号とリンク型は完全なAS経路にprependedされます、そして、ASカウント分野は1つ増加されます。 BGP UPDATEメッセージがINTERNALリンクの上に伝播されるなら、変更されていなく渡された完全なAS経路とASは同じように滞在を数えます。 ゲートウェイ野原を送付者の自己のアドレスに取り替えます。
6. Acknowledgements
6. 承認
We would like to express our thanks to Len Bosack (cisco Systems), Jeff Honig (Cornell University) and all members of the IWG task force for their contributions to this document.
このドキュメントへの彼らの貢献のためにレンBosack(コクチマスSystems)、ジェフ・ホニッグ(コーネル大学)、およびIWG特別委員会のすべてのメンバーに感謝したいと思います。
Lougheed & Rekhter [Page 13] RFC 1105 BGP June 1989
ロッキードとRekhter[13ページ]RFC1105BGP1989年6月
Appendix 1
付録1
BGP FSM State Transitions and Actions.
BGP FSMは変遷と動作を述べます。
This Appendix discusses the transitions between states in the BGP FSM in response to BGP events. The following is the list of these states and events.
このAppendixはBGP出来事に対応してBGP FSMの州の間の変遷について議論します。 ↓これはこれらの州と出来事のリストです。
BGP States:
BGP州:
1 - BGP_Idle
2 - BGP_Active
3 - BGP_OpenSent
4 - BGP_OpenConfirm
5 - BGP_Established
1--活動していない2--_のアクティブなBGP3--BGP_OpenSent4--BGP_OpenConfirm5--BGP_が設立したBGP_
BGP Events:
BGP出来事:
1 - BGP Start
2 - BGP Transport connection open
3 - BGP Transport connection closed
4 - BGP Transport connection open failed
5 - Receive OPEN message
6 - Receive OPEN CONFIRM message
7 - Receive KEEPALIVE message
8 - Receive UPDATE messages
9 - Receive NOTIFICATION message
10 - Holdtime timer expired
11 - KeepAlive timer expired
12 - Receive CEASE message
13 - BGP Stop
1--BGP Start2--BGP Transport接続は4を閉じました--オープンなBGP Transport接続が5に失敗したというBGP Transport接続開いている3はオープンメッセージ6を受け取ります--OPEN CONFIRMメッセージ7を受け取ってください--KEEPALIVEメッセージ8を受け取ってください--UPDATEメッセージ9を受け取ってください--NOTIFICATIONメッセージ10を受け取ってください--Holdtimeタイマは11--KeepAliveタイマ満期の12--CEASEメッセージ13を受け取ります--BGP Stopを吐き出しました。
The following table describes the state transitions of the BGP FSM and the actions triggered by these transitions.
以下のテーブルはBGP FSMの状態遷移とこれらの変遷で引き起こされた動作について説明します。
Lougheed & Rekhter [Page 14] RFC 1105 BGP June 1989
ロッキードとRekhter[14ページ]RFC1105BGP1989年6月
Event Actions Message Sent Next State
--------------------------------------------------------------------
BGP_Idle (1)
1 Initialize resources none 2
BGP_Active (2)
2 Initialize resources OPEN 3
4 none none 2
13 Release resources none 1
次の状態に送られたイベント動作メッセージ-------------------------------------------------------------------- (1) BGP_Idleの1Initializeのリソース、なにも、2BGP_Active(2)2Initializeリソースオープン、3 4、なにも、なにも、2つの13Releaseリソース、なにも、1
BGP_OpenSent(3)
3 none none 1
5 Process OPEN is OK OPEN CONFIRM 4
Process OPEN Message failed NOTIFICATION 1
11 Restart KeepAlive timer KEEPALIVE 3
13 Release resources none 1
BGP_OpenSent(3)3、なにも、なにも、1 5ProcessオープンがなにもにOK OPEN CONFIRM4ProcessオープンMessage失敗したNOTIFICATION1 11Restart KeepAliveタイマKEEPALIVE3 13Releaseリソースである、1
BGP_OpenConfirm (4)
6 Complete initialization none 5
3 none none 1
10 Close transport connection none 1
11 Restart KeepAlive timer KEEPALIVE 4
13 Release resources none 1
BGP_OpenConfirm(4)6Complete初期化、なにも、5 3、なにも、なにも、1、10Closeが接続のためになにも輸送しない、1 11Restart KeepAliveタイマKEEPALIVE4 13Releaseリソース、なにも、1
BGP_Established (5)
7 Process KEEPALIVE none 5
8 Process UPDATE is OK UPDATE 5
Process UPDATE failed NOTIFICATION 5
9 Process NOTIFICATION none 5
10 Close transport connection none 1
11 Restart KeepAlive timer KEEPALIVE 5
12 Close transport connection NOTIFICATION 1
13 Release resources none 1
--------------------------------------------------------------------
BGP_Established(5)7Process KEEPALIVE、なにも、5 8Process UPDATEによるOK UPDATE5Process UPDATEがなにもにNOTIFICATION5 9Process NOTIFICATIONに失敗したということである、5、10Closeが接続のためになにも輸送しない、1個の11Restart KeepAliveタイマKEEPALIVE5 12Closeがなにもに接続NOTIFICATION1 13Releaseリソースを輸送する、1--------------------------------------------------------------------
All other state-event combinations are considered fatal errors and cause the termination of the BGP transport connection (if necessary) and a transition to the BGP_Idle state.
他の州イベント組み合わせはすべて、致命的な誤りであると考えられて、BGP輸送接続(必要なら)の終了とBGP_Idle状態への変遷を引き起こします。
Lougheed & Rekhter [Page 15] RFC 1105 BGP June 1989
ロッキードとRekhter[15ページ]RFC1105BGP1989年6月
The following is a condensed version of the above state transition table.
↓これは上の状態遷移テーブルの縮約版です。
Events|BGP_Idle BGP_Active BGP_OpenSent BGP_OpenConfirm BGP_Estab
| (1) | (2) | (3) | (4) | (5)
|-------------------------------------------------------------
1 | 2 | | | |
| | | | |
2 | | 3 | | |
| | | | |
3 | | | 1 | 1 |
| | | | |
4 | | 2 | | |
| | | | |
5 | | | 4 or 1 | |
| | | | |
6 | | | | 5 |
| | | | |
7 | | | | | 5
| | | | |
8 | | | | | 5
| | | | |
9 | | | | | 5
| | | | |
10 | | | | 1 | 1
| | | | |
11 | | | 3 | 4 | 5
| | | | |
12 | | | | | 1
| | | | |
13 | | 1 | 1 | 1 | 1
| | | | |
--------------------------------------------------------------
出来事|_の使用されていない_アクティブな_BGP BGP BGP_OpenSent BGP OpenConfirm BGP_Estab| (1) | (2) | (3) | (4) | (5) |------------------------------------------------------------- 1 | 2 | | | | | | | | | 2 | | 3 | | | | | | | | 3 | | | 1 | 1 | | | | | | 4 | | 2 | | | | | | | | 5 | | | 4か1| | | | | | | 6 | | | | 5 | | | | | | 7 | | | | | 5 | | | | | 8 | | | | | 5 | | | | | 9 | | | | | 5 | | | | | 10 | | | | 1 | 1 | | | | | 11 | | | 3 | 4 | 5 | | | | | 12 | | | | | 1 | | | | | 13 | | 1 | 1 | 1 | 1 | | | | | --------------------------------------------------------------
Lougheed & Rekhter [Page 16] RFC 1105 BGP June 1989
ロッキードとRekhter[16ページ]RFC1105BGP1989年6月
References
参照
[1] Mills, D., "Exterior Gateway Protocol Formal Specification", RFC
904, BBN, April 1984.
[1] 工場、D.、「外のゲートウェイプロトコル形式仕様」、RFC904、BBN、1984年4月。
[2] Rekhter, Y., "EGP and Policy Based Routing in the New NSFNET
Backbone", RFC 1092, T. J. Watson Research Center, February 1989.
[2] Rekhter、Y.、「EGPと方針は新しいNSFNET背骨におけるルート設定を基礎づけました」、RFC1092、T.J.ワトソン研究所、1989年2月。
[3] Braun, H-W., "The NSFNET Routing Architecture", RFC 1093,
MERIT/NSFNET Project, February 1989.
[3] ブラウン、H-W.、「NSFNETルート設定構造」、RFC1093、長所/NSFNETは1989年2月に突出します。
[4] Postel, J., "Transmission Control Protocol - DARPA Internet
Program Protocol Specification", RFC 793, DARPA, September 1981.
[4] ポステル、J.、「転送管理は議定書を作ります--DARPAインターネットはプロトコル仕様をプログラムする」RFC793、DARPA、1981年9月。
[5] Cheriton, D., "VMTP: Versatile Message Transaction Protocol", RFC
1045, Stanford University, February 1988.
[5]Cheriton、D.、「VMTP:」 「多能なメッセージ取引プロトコル」、RFC1045、スタンフォード大学、1988年2月。
Authors' Addresses
作者のアドレス
Kirk Lougheed cisco Systems, Inc. 1360 Willow Road, Suite 201 Menlo Park, CA 94025
カークロッキードコクチマスSystems Inc.1360Willow Road、Suite201メンローパーク、カリフォルニア 94025
Phone: (415) 326-1941
以下に電話をしてください。 (415) 326-1941
Email: LOUGHEED@MATHOM.CISCO.COM
メール: LOUGHEED@MATHOM.CISCO.COM
Jacob Rekhter T.J. Watson Research Center IBM Corporation P.O. Box 218 Yorktown Heights, NY 10598
ニューヨーク ヤコブRekhter T.J.ワトソン研究所IBM社の私書箱218ヨークタウンの高さ、10598
Phone: (914) 945-3896
以下に電話をしてください。 (914) 945-3896
Email: YAKOV@IBM.COM
メール: YAKOV@IBM.COM
Lougheed & Rekhter [Page 17]
ロッキードとRekhter[17ページ]
一覧
スポンサーリンク
