[要約] RFC 7854は、BGPモニタリングプロトコル（BMP）に関する標準仕様です。BMPは、BGPルーターのモニタリングとデータ収集を目的としています。
Internet Engineering Task Force (IETF) J. Scudder, Ed.
Request for Comments: 7854 Juniper Networks
Category: Standards Track R. Fernando
ISSN: 2070-1721 Cisco Systems
S. Stuart
Google
June 2016
BGP Monitoring Protocol (BMP)
BGP監視プロトコル（BMP）
Abstract
概要
This document defines the BGP Monitoring Protocol (BMP), which can be used to monitor BGP sessions. BMP is intended to provide a convenient interface for obtaining route views. Prior to the introduction of BMP, screen scraping was the most commonly used approach to obtaining such views. The design goals are to keep BMP simple, useful, easily implemented, and minimally service affecting. BMP is not suitable for use as a routing protocol.
このドキュメントでは、BGPセッションの監視に使用できるBGP監視プロトコル（BMP）を定義します。 BMPは、ルートビューを取得するための便利なインターフェイスを提供することを目的としています。 BMPが導入される前は、画面のスクレイピングがこのようなビューを取得するための最も一般的なアプローチでした。設計目標は、BMPをシンプル、便利、簡単に実装でき、サービスへの影響を最小限に抑えることです。 BMPはルーティングプロトコルとしての使用には適していません。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7854.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7854で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2016 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日より前に公開または公開されたIETFドキュメントまたはIETFコントリビューションの素材が含まれている場合があります。この素材の一部で著作権を管理している人が、IETFトラストにそのような素材の変更を許可する権利を付与していない可能性がありますIETF標準プロセス外。このような資料の著作権を管理する人から適切なライセンスを取得せずに、このドキュメントをIETF標準プロセス外で変更したり、その派生物をIETF標準プロセス外で作成したりすることはできません。 RFCとして、またはそれを英語以外の言語に翻訳するための出版物。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview of BMP Operation . . . . . . . . . . . . . . . . . . 4
3.1. BMP Messages . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Connection Establishment and Termination . . . . . . . . 5
3.3. Lifecycle of a BMP Session . . . . . . . . . . . . . . . 6
4. BMP Message Format . . . . . . . . . . . . . . . . . . . . . 7
4.1. Common Header . . . . . . . . . . . . . . . . . . . . . . 7
4.2. Per-Peer Header . . . . . . . . . . . . . . . . . . . . . 8
4.3. Initiation Message . . . . . . . . . . . . . . . . . . . 10
4.4. Information TLV . . . . . . . . . . . . . . . . . . . . . 10
4.5. Termination Message . . . . . . . . . . . . . . . . . . . 11
4.6. Route Monitoring . . . . . . . . . . . . . . . . . . . . 12
4.7. Route Mirroring . . . . . . . . . . . . . . . . . . . . . 12
4.8. Stats Reports . . . . . . . . . . . . . . . . . . . . . . 13
4.9. Peer Down Notification . . . . . . . . . . . . . . . . . 16
4.10. Peer Up Notification . . . . . . . . . . . . . . . . . . 17
5. Route Monitoring . . . . . . . . . . . . . . . . . . . . . . 18
6. Route Mirroring . . . . . . . . . . . . . . . . . . . . . . . 19
7. Stat Reports . . . . . . . . . . . . . . . . . . . . . . . . 19
8. Other Considerations . . . . . . . . . . . . . . . . . . . . 20
8.1. Multiple Instances . . . . . . . . . . . . . . . . . . . 20
8.2. Locally Originated Routes . . . . . . . . . . . . . . . . 20
9. Using BMP . . . . . . . . . . . . . . . . . . . . . . . . . . 20
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
10.1. BMP Message Types . . . . . . . . . . . . . . . . . . . 21
10.2. BMP Peer Types . . . . . . . . . . . . . . . . . . . . . 21
10.3. BMP Peer Flags . . . . . . . . . . . . . . . . . . . . . 22
10.4. BMP Statistics Types . . . . . . . . . . . . . . . . . . 22
10.5. BMP Initiation Message TLVs . . . . . . . . . . . . . . 23
10.6. BMP Termination Message TLVs . . . . . . . . . . . . . . 23
10.7. BMP Termination Message Reason Codes . . . . . . . . . . 23
10.8. BMP Peer Down Reason Codes . . . . . . . . . . . . . . . 24
10.9. Route Mirroring TLVs . . . . . . . . . . . . . . . . . . 24
10.10. BMP Route Mirroring Information Codes . . . . . . . . . 24
11. Security Considerations . . . . . . . . . . . . . . . . . . . 25
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
12.1. Normative References . . . . . . . . . . . . . . . . . . 25
12.2. Informative References . . . . . . . . . . . . . . . . . 26
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27
Many researchers and network operators wish to have access to the contents of routers' BGP Routing Information Bases (RIBs) as well as a view of protocol updates the router is receiving. This monitoring task cannot be realized by standard protocol mechanisms. Prior to the introduction of BMP, this data could only be obtained through screen scraping.
多くの研究者やネットワークオペレーターは、ルーターのBGPルーティング情報ベース（RIB）のコンテンツや、ルーターが受信しているプロトコル更新のビューにアクセスしたいと考えています。この監視タスクは、標準のプロトコルメカニズムでは実現できません。 BMPが導入される前は、このデータはスクリーンスクレイピングによってのみ取得できました。
BMP provides access to the Adj-RIB-In of a peer on an ongoing basis and a periodic dump of certain statistics the monitoring station can use for further analysis. From a high level, BMP can be thought of as the result of multiplexing together the messages received on the various monitored BGP sessions.
BMPは、継続的にピアのAdj-RIB-Inへのアクセスを提供し、監視ステーションがさらに分析するために使用できる特定の統計の定期的なダンプを提供します。高レベルでは、BMPは、監視対象のさまざまなBGPセッションで受信されたメッセージを多重化した結果と考えることができます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの "は、RFC 2119 [RFC2119]で説明されているように解釈されます。
o Adj-RIB-In: As defined in [RFC4271], "The Adj-RIBs-In contains unprocessed routing information that has been advertised to the local BGP speaker by its peers." This is also referred to as the pre-policy Adj-RIB-In in this document.
o Adj-RIB-In：[RFC4271]で定義されているように、「Adj-RIBs-Inには、ピアによってローカルBGPスピーカーにアドバタイズされた未処理のルーティング情報が含まれています。」これは、このドキュメントでは事前ポリシーAdj-RIB-Inとも呼ばれます。
o Post-Policy Adj-RIB-In: The result of applying inbound policy to an Adj-RIB-In, but prior to the application of route selection to form the Loc-RIB.
o ポリシー後のAdj-RIB-In：インバウンドポリシーをAdj-RIB-Inに適用した結果ですが、ルート選択を適用してLoc-RIBを形成する前です。
The following are the messages provided by BMP:
以下は、BMPによって提供されるメッセージです。
o Route Monitoring (RM): Used to provide an initial dump of all routes received from a peer, as well as an ongoing mechanism that sends the incremental routes advertised and withdrawn by a peer to the monitoring station.
o ルートモニタリング（RM）：ピアから受信したすべてのルートの初期ダンプ、およびピアによってアドバタイズおよび撤回された増分ルートをモニタリングステーションに送信する継続的なメカニズムを提供するために使用されます。
o Peer Down Notification: A message sent to indicate that a peering session has gone down with information indicating the reason for the session disconnect.
o ピアダウン通知：ピアリングセッションがダウンしたことを示すために送信されたメッセージで、セッションが切断された理由を示します。
o Stats Reports (SR): An ongoing dump of statistics that can be used by the monitoring station as a high-level indication of the activity going on in the router.
o 統計レポート（SR）：監視ステーションがルーターで行われているアクティビティの高レベルの指標として使用できる統計の継続的なダンプ。
o Peer Up Notification: A message sent to indicate that a peering session has come up. The message includes information regarding the data exchanged between the peers in their OPEN messages, as well as information about the peering TCP session itself. In addition to being sent whenever a peer transitions to the Established state, a Peer Up Notification is sent for each peer in the Established state when the BMP session itself comes up.
o ピアアップ通知：ピアリングセッションがアップしたことを示すために送信されるメッセージ。メッセージには、OPENメッセージ内のピア間で交換されたデータに関する情報と、ピアリングTCPセッション自体に関する情報が含まれます。ピアがEstablished状態に遷移するたびに送信されるだけでなく、BMPセッション自体が起動したときに、確立済み状態のピアごとにピアアップ通知が送信されます。
o Initiation: A means for the monitored router to inform the monitoring station of its vendor, software version, and so on.
o 開始：監視対象ルーターが監視ステーションにベンダー、ソフトウェアバージョンなどを通知するための手段。
o Termination: A means for the monitored router to inform the monitoring station of why it is closing a BMP session.
o 終了：監視対象ルーターが監視ステーションにBMPセッションを閉じている理由を通知する手段。
o Route Mirroring: A means for the monitored router to send verbatim duplicates of messages as received. Can be used to exactly mirror a monitored BGP session. Can also be used to report malformed BGP Protocol Data Units (PDUs).
o ルートミラーリング：監視対象ルーターが受信したメッセージの逐語的な複製を送信するための手段。監視対象のBGPセッションを正確にミラーリングするために使用できます。不正なBGPプロトコルデータユニット（PDU）の報告にも使用できます。
BMP operates over TCP. All options are controlled by configuration on the monitored router. No BMP message is ever sent from the monitoring station to the monitored router. The monitored router MAY take steps to prevent the monitoring station from sending data (for example, by half-closing the TCP session or setting its window size to 0) or it MAY silently discard any data sent by the monitoring station.
BMPはTCP上で動作します。すべてのオプションは、監視対象ルーターの構成によって制御されます。監視ステーションから監視対象ルーターにBMPメッセージが送信されることはありません。監視対象のルーターは、監視ステーションがデータを送信しないようにする（たとえば、TCPセッションを半分閉じる、またはそのウィンドウサイズを0に設定する）ことができます。または、監視ステーションが送信したデータを警告なく破棄する場合があります。
The router may be monitored by one or more monitoring stations. With respect to each (router and monitoring station) pair, one party is active with respect to TCP session establishment, and the other party is passive. Which party is active and which is passive is controlled by configuration.
ルーターは、1つ以上の監視ステーションによって監視できます。各（ルーターと監視ステーション）のペアに関して、一方のパーティはTCPセッションの確立に関してアクティブであり、もう一方のパーティはパッシブです。どちらがアクティブでどちらがパッシブであるかは、構成によって制御されます。
The passive party is configured to listen on a particular TCP port and the active party is configured to establish a connection to that port. If the active party is unable to connect to the passive party, it periodically retries the connection. Retries MUST be subject to some variety of backoff. Exponential backoff with a default initial backoff of 30 seconds and a maximum of 720 seconds is suggested.
パッシブパーティは特定のTCPポートでリッスンするように構成され、アクティブパーティはそのポートへの接続を確立するように構成されます。アクティブパーティがパッシブパーティに接続できない場合、定期的に接続を再試行します。再試行には、さまざまなバックオフが必要です。デフォルトの初期バックオフは30秒、最大は720秒の指数バックオフが推奨されます。
The router MAY restrict the set of IP addresses from which it will accept connections. It SHOULD restrict the number of simultaneous connections it will permit from a given IP address. The default value for this restriction SHOULD be 1, though an implementation MAY permit this restriction to be disabled in configuration. The router MUST also restrict the rate at which sessions may be established. A suggested default is an establishment rate of 2 sessions per minute.
ルーターは、接続を受け入れるIPアドレスのセットを制限してもよい（MAY）。特定のIPアドレスから許可する同時接続数を制限する必要があります（SHOULD）。この制限のデフォルト値は1である必要があります（SHOULD）が、実装では、この制限を構成で無効にすることを許可する場合があります。ルータはまた、セッションが確立されるかもしれないレートを制限しなければなりません。推奨されるデフォルトは、1分あたり2セッションの確立率です。
A router (or management station) MAY implement logic to detect redundant connections, as might occur if both parties are configured to be active, and MAY elect to terminate redundant connections. A Termination reason code is defined for this purpose.
ルーター（または管理ステーション）は、両方のパーティがアクティブに構成されている場合に発生する可能性があるように、冗長接続を検出するロジックを実装でき、冗長接続を終了することを選択できます（MAY）。この目的のために、終了理由コードが定義されています。
Once a connection is established, the router sends messages over it. There is no initialization or handshaking phase, messages are simply sent as soon as the connection is established.
接続が確立されると、ルーターはその接続を介してメッセージを送信します。初期化やハンドシェイクのフェーズはありません。接続が確立されるとすぐにメッセージが送信されます。
If the monitoring station intends to end or restart BMP processing, it simply drops the connection.
監視ステーションがBMP処理を終了または再起動する場合は、単に接続をドロップします。
A router is configured to speak BMP to one or more monitoring stations. It MAY be configured to send monitoring information for only a subset of its BGP peers. Otherwise, all BGP peers are assumed to be monitored.
ルーターは、1つ以上の監視ステーションとBMPを話すように構成されています。 BGPピアのサブセットのみの監視情報を送信するように構成できます。それ以外の場合、すべてのBGPピアが監視されていると見なされます。
A BMP session begins when the active party (either router or management station, as determined by configuration) successfully opens a TCP session (the "BMP session"). Once the session is up, the router begins to send BMP messages. It MUST begin by sending an Initiation message. It subsequently sends a Peer Up message over the BMP session for each of its monitored BGP peers that is in the Established state. It follows by sending the contents of its Adj-RIBs-In (pre-policy, post-policy, or both, see Section 5) encapsulated in Route Monitoring messages. Once it has sent all the routes for a given peer, it MUST send an End-of-RIB message for that peer; when End-of-RIB has been sent for each monitored peer, the initial table dump has completed. (A monitoring station that only wants to gather a table dump could close the connection once it has gathered an End-of-RIB or Peer Down message corresponding to each Peer Up message.)
BMPセッションは、アクティブなパーティ（ルーターまたは管理ステーション、構成によって決定）が正常にTCPセッション（「BMPセッション」）を開いたときに始まります。セッションが起動すると、ルータはBMPメッセージの送信を開始します。これは、開始メッセージを送信することから始める必要があります。その後、確立された状態にある監視対象の各BGPピアのBMPセッションを介してピアアップメッセージを送信します。続いて、ルートモニタリングメッセージにカプセル化されたAdj-RIBs-In（事前ポリシー、事後ポリシー、または両方、セクション5を参照）のコンテンツを送信します。特定のピアのすべてのルートを送信したら、そのピアのEnd-of-RIBメッセージを送信する必要があります。監視対象のピアごとにEnd-of-RIBが送信されると、初期テーブルダンプが完了します。 （テーブルダンプのみを収集する監視ステーションは、各ピアアップメッセージに対応するエンドオブRIBまたはピアダウンメッセージを収集すると、接続を閉じることができます。）
Following the initial table dump, the router sends incremental updates encapsulated in Route Monitoring messages. It MAY periodically send Stats Reports or even new Initiation messages, according to configuration. If any new monitored BGP peer becomes Established, a corresponding Peer Up message is sent. If any BGP peers for which Peer Up messages were sent transition out of the Established state, corresponding Peer Down messages are sent.
初期テーブルダンプに続いて、ルータはルートモニタリングメッセージにカプセル化された増分更新を送信します。構成に応じて、定期的に統計レポートまたは新しい開始メッセージを送信する場合があります。監視対象の新しいBGPピアが確立されると、対応するピアアップメッセージが送信されます。 Peer Upメッセージが送信されたBGPピアがEstablished状態から移行すると、対応するPeer Downメッセージが送信されます。
A BMP session ends when the TCP session that carries it is closed for any reason. The router MAY send a Termination message prior to closing the session.
BMPセッションは、それを運ぶTCPセッションが何らかの理由で閉じられると終了します。ルータは、セッションを閉じる前に終了メッセージを送信する場合があります。
The following common header appears in all BMP messages. The rest of the data in a BMP message is dependent on the Message Type field in the common header.
次の共通ヘッダーは、すべてのBMPメッセージに表示されます。 BMPメッセージの残りのデータは、共通ヘッダーのメッセージタイプフィールドに依存します。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Msg. Type |
+---------------+
o Version (1 byte): Indicates the BMP version. This is set to '3' for all messages defined in this specification. ('1' and '2' were used by draft versions of this document.) Version 0 is reserved and MUST NOT be sent.
o バージョン（1バイト）：BMPバージョンを示します。これは、この仕様で定義されているすべてのメッセージに対して「3」に設定されます。 （「1」と「2」はこのドキュメントのドラフトバージョンで使用されていました。）バージョン0は予約されており、送信してはなりません。
o Message Length (4 bytes): Length of the message in bytes (including headers, data, and encapsulated messages, if any).
o メッセージの長さ（4バイト）：メッセージの長さ（バイト、ヘッダー、データ、およびカプセル化されたメッセージ（ある場合）を含む）。
o Message Type (1 byte): This identifies the type of the BMP message. A BMP implementation MUST ignore unrecognized message types upon receipt.
o メッセージタイプ（1バイト）：BMPメッセージのタイプを識別します。 BMP実装は、受信時に認識されないメッセージタイプを無視する必要があります。
* Type = 0: Route Monitoring * Type = 1: Statistics Report * Type = 2: Peer Down Notification * Type = 3: Peer Up Notification * Type = 4: Initiation Message * Type = 5: Termination Message * Type = 6: Route Mirroring Message
* タイプ= 0：ルートモニタリング*タイプ= 1：統計レポート*タイプ= 2：ピアダウン通知*タイプ= 3：ピアアップ通知*タイプ= 4：開始メッセージ*タイプ= 5：終了メッセージ*タイプ= 6：ルートミラーリングメッセージ
The per-peer header follows the common header for most BMP messages. The rest of the data in a BMP message is dependent on the Message Type field in the common header.
ピアごとのヘッダーは、ほとんどのBMPメッセージの共通ヘッダーに従います。 BMPメッセージの残りのデータは、共通ヘッダーのメッセージタイプフィールドに依存します。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer Type | Peer Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer Distinguisher (present based on peer type) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer Address (16 bytes) |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer AS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer BGP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp (seconds) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp (microseconds) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Peer Type (1 byte): Identifies the type of peer. Currently, three types of peers are identified:
o ピアタイプ（1バイト）：ピアのタイプを識別します。現在、3つのタイプのピアが識別されています。
* Peer Type = 0: Global Instance Peer * Peer Type = 1: RD Instance Peer * Peer Type = 2: Local Instance Peer
* ピアタイプ= 0：グローバルインスタンスピア*ピアタイプ= 1：RDインスタンスピア*ピアタイプ= 2：ローカルインスタンスピア
o Peer Flags (1 byte): These flags provide more information about the peer. The flags are defined as follows:
o ピアフラグ（1バイト）：これらのフラグは、ピアに関する詳細情報を提供します。フラグは次のように定義されています。
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|V|L|A| Reserved|
+-+-+-+-+-+-+-+-+
* The V flag indicates that the Peer address is an IPv6 address. For IPv4 peers, this is set to 0.
* Vフラグは、ピアアドレスがIPv6アドレスであることを示します。 IPv4ピアの場合、これは0に設定されます。
* The L flag, if set to 1, indicates that the message reflects the post-policy Adj-RIB-In (i.e., its path attributes reflect the application of inbound policy). It is set to 0 if the message reflects the pre-policy Adj-RIB-In. Locally sourced routes also carry an L flag of 1. See Section 5 for further detail. This flag has no significance when used with route mirroring messages (Section 4.7).
* Lフラグが1に設定されている場合、メッセージはポリシー後のAdj-RIB-Inを反映していることを示します（つまり、そのパス属性はインバウンドポリシーの適用を反映しています）。メッセージがポリシー前のAdj-RIB-Inを反映している場合、0に設定されます。ローカルソースルートもLフラグが1です。詳細については、セクション5を参照してください。このフラグは、ルートミラーリングメッセージ（セクション4.7）と共に使用した場合は意味がありません。
* The A flag, if set to 1, indicates that the message is formatted using the legacy 2-byte AS_PATH format. If set to 0, the message is formatted using the 4-byte AS_PATH format [RFC6793]. A BMP speaker MAY choose to propagate the AS_PATH information as received from its peer, or it MAY choose to reformat all AS_PATH information into a 4-byte format regardless of how it was received from the peer. In the latter case, AS4_PATH or AS4_AGGREGATOR path attributes SHOULD NOT be sent in the BMP UPDATE message. This flag has no significance when used with route mirroring messages (Section 4.7).
* Aフラグは、1に設定されている場合、メッセージが従来の2バイトのAS_PATH形式を使用してフォーマットされていることを示します。 0に設定すると、メッセージは4バイトのAS_PATH形式[RFC6793]を使用してフォーマットされます。 BMPスピーカーは、ピアから受信したAS_PATH情報を伝播することを選択することも、ピアからの受信方法に関係なく、すべてのAS_PATH情報を4バイト形式に再フォーマットすることを選択することもできます（MAY）。後者の場合、AS4_PATHまたはAS4_AGGREGATORパス属性はBMP UPDATEメッセージで送信してはなりません（SHOULD NOT）。このフラグは、ルートミラーリングメッセージ（セクション4.7）と共に使用した場合は意味がありません。
* The remaining bits are reserved for future use. They MUST be transmitted as 0 and their values MUST be ignored on receipt.
* 残りのビットは将来の使用のために予約されています。それらは0として送信されなければならず、それらの値は受信時に無視されなければなりません。
o Peer Distinguisher (8 bytes): Routers today can have multiple instances (example: Layer 3 Virtual Private Networks (L3VPNs) [RFC4364]). This field is present to distinguish peers that belong to one address domain from the other.
o ピア識別子（8バイト）：今日のルーターは複数のインスタンスを持つことができます（例：レイヤー3仮想プライベートネットワーク（L3VPN）[RFC4364]）。このフィールドは、1つのアドレスドメインに属するピアを他のドメインから区別するために存在します。
If the peer is a "Global Instance Peer", this field is zero-filled. If the peer is a "RD Instance Peer", it is set to the route distinguisher of the particular instance the peer belongs to. If the peer is a "Local Instance Peer", it is set to a unique, locally defined value. In all cases, the effect is that the combination of the Peer Type and Peer Distinguisher is sufficient to disambiguate peers for which other identifying information might overlap.
ピアが「グローバルインスタンスピア」の場合、このフィールドはゼロで埋められます。ピアが「RDインスタンスピア」の場合、ピアが属する特定のインスタンスのルート識別子に設定されます。ピアが「ローカルインスタンスピア」の場合、ローカルに定義された一意の値に設定されます。すべての場合において、他の識別情報が重複している可能性のあるピアを明確にするのに、ピアタイプとピア識別子の組み合わせで十分です。
o Peer Address: The remote IP address associated with the TCP session over which the encapsulated PDU was received. It is 4 bytes long if an IPv4 address is carried in this field (with the 12 most significant bytes zero-filled) and 16 bytes long if an IPv6 address is carried in this field.
o ピアアドレス：カプセル化されたPDUが受信されたTCPセッションに関連付けられたリモートIPアドレス。このフィールドにIPv4アドレスが含まれている場合（最上位12バイトがゼロで埋められている場合）は4バイト長であり、IPv6アドレスがこのフィールドに含まれている場合は16バイト長です。
o Peer AS: The Autonomous System number of the peer from which the encapsulated PDU was received. If a 16-bit AS number is stored in this field [RFC6793], it should be padded with zeroes in the 16 most significant bits.
o ピアAS：カプセル化されたPDUを受信したピアの自律システム番号。このフィールド[RFC6793]に16ビットのAS番号が格納されている場合は、16の最上位ビットにゼロを埋め込む必要があります。
o Peer BGP ID: The BGP Identifier of the peer from which the encapsulated PDU was received.
o ピアBGP ID：カプセル化されたPDUの送信元であるピアのBGP ID。
o Timestamp: The time when the encapsulated routes were received (one may also think of this as the time when they were installed in the Adj-RIB-In), expressed in seconds and microseconds since midnight (zero hour), January 1, 1970 (UTC). If zero, the time is unavailable. Precision of the timestamp is implementation-dependent.
o タイムスタンプ：カプセル化されたルートが受信された時間（Adj-RIB-Inにインストールされた時間と考えることもできます）。1970年1月1日の午前0時（ゼロ時間）からの秒とマイクロ秒で表されます（ UTC）。ゼロの場合、時間は利用できません。タイムスタンプの精度は実装に依存します。
The initiation message provides a means for the monitored router to inform the monitoring station of its vendor, software version, and so on. An initiation message MUST be sent as the first message after the TCP session comes up. An initiation message MAY be sent at any point thereafter, if warranted by a change on the monitored router.
開始メッセージは、監視対象ルーターが監視ステーションにベンダー、ソフトウェアバージョンなどを通知する手段を提供します。開始メッセージは、TCPセッションが起動した後の最初のメッセージとして送信する必要があります。監視対象ルーターの変更により保証された場合、その後の任意の時点で開始メッセージが送信される場合があります。
The initiation message consists of the common BMP header followed by two or more Information TLVs (Section 4.4) containing information about the monitored router. The sysDescr and sysName Information TLVs MUST be sent, any others are optional. The string TLV MAY be included multiple times.
開始メッセージは、監視対象のルーターに関する情報を含む2つ以上の情報TLV（セクション4.4）が後に続く共通のBMPヘッダーで構成されます。 sysDescrおよびsysName情報TLVを送信する必要があります。他のTLVはオプションです。文字列TLVは複数回含めることができます。
The Information TLV is used by the Initiation (Section 4.3) and Peer Up (Section 4.10) messages.
情報TLVは、開始（セクション4.3）およびピアアップ（セクション4.10）メッセージで使用されます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Information Type | Information Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Information (variable) |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Information Type (2 bytes): Type of information provided. Defined types are:
o 情報タイプ（2バイト）：提供される情報のタイプ。定義されているタイプは次のとおりです。
* Type = 0: String. The Information field contains a free-form UTF-8 string whose length is given by the Information Length field. The value is administratively assigned. There is no requirement to terminate the string with a null (or any other particular) character -- the Information Length field gives its termination. If multiple strings are included, their ordering MUST be preserved when they are reported.
* タイプ= 0：文字列。情報フィールドには、情報の長さフィールドで指定された長さの自由形式のUTF-8文字列が含まれます。値は管理上割り当てられます。文字列をnull（またはその他の特定の）文字で終了する必要はありません。情報の長さフィールドで終了します。複数の文字列が含まれている場合、それらが報告されたときにそれらの順序を維持する必要があります。
* Type = 1: sysDescr. The Information field contains an ASCII string whose value MUST be set to be equal to the value of the sysDescr MIB-II [RFC1213] object.
* タイプ= 1：sysDescr。情報フィールドには、sysDescr MIB-II [RFC1213]オブジェクトの値と同じ値に設定する必要があるASCII文字列が含まれています。
* Type = 2: sysName. The Information field contains an ASCII string whose value MUST be set to be equal to the value of the sysName MIB-II [RFC1213] object.
* タイプ= 2：sysName。情報フィールドには、sysName MIB-II [RFC1213]オブジェクトの値と同じ値に設定する必要があるASCII文字列が含まれています。
o Information Length (2 bytes): The length of the following Information field, in bytes.
o 情報の長さ（2バイト）：次の情報フィールドの長さ（バイト単位）。
o Information (variable): Information about the monitored router, according to the type.
o 情報（変数）：タイプに応じた、監視対象ルーターに関する情報。
The termination message provides a way for a monitored router to indicate why it is terminating a session. Although use of this message is RECOMMENDED, a monitoring station must always be prepared for the session to terminate with no message. Once the router has sent a termination message, it MUST close the TCP session without sending any further messages. Likewise, the monitoring station MUST close the TCP session after receiving a termination message.
終了メッセージは、監視対象ルーターがセッションを終了する理由を示す方法を提供します。このメッセージの使用は推奨されていますが、セッションがメッセージなしで終了するように、監視ステーションを常に準備する必要があります。ルーターが終了メッセージを送信すると、それ以上メッセージを送信せずにTCPセッションを閉じる必要があります。同様に、監視ステーションは、終了メッセージを受信した後にTCPセッションを閉じる必要があります。
The termination message consists of the common BMP header followed by one or more TLVs containing information about the reason for the termination, as follows:
終了メッセージは、次のように、共通のBMPヘッダーと、それに続く終了の理由に関する情報を含む1つ以上のTLVで構成されます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Information Type | Information Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Information (variable) |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Information Type (2 bytes): Type of information provided. Defined types are:
o 情報タイプ（2バイト）：提供される情報のタイプ。定義されているタイプは次のとおりです。
* Type = 0: String. The Information field contains a free-form UTF-8 string whose length is given by the Information Length field. Inclusion of this TLV is optional. It MAY be used to provide further detail for any of the defined reasons. Multiple String TLVs MAY be included in the message.
* タイプ= 0：文字列。情報フィールドには、情報の長さフィールドで指定された長さの自由形式のUTF-8文字列が含まれます。このTLVの組み込みはオプションです。定義された理由のいずれかについて、詳細を提供するために使用できます。複数の文字列TLVがメッセージに含まれる場合があります。
* Type = 1: Reason. The Information field contains a 2-byte code indicating the reason that the connection was terminated. Some reasons may have further TLVs associated with them. Inclusion of this TLV is REQUIRED. Defined reasons are:
* タイプ= 1：理由。情報フィールドには、接続が終了した理由を示す2バイトのコードが含まれています。いくつかの理由により、さらにTLVが関連付けられる場合があります。このTLVを含める必要があります。定義されている理由は次のとおりです。
+ Reason = 0: Session administratively closed. The session might be re-initiated.
+ 理由= 0：セッションは管理上閉じられました。セッションが再開される可能性があります。
+ Reason = 1: Unspecified reason.
+ 理由= 1：不特定の理由。
+ Reason = 2: Out of resources. The router has exhausted resources available for the BMP session.
+ 理由= 2：リソース不足。ルータは、BMPセッションに使用できるリソースを使い果たしました。
+ Reason = 3: Redundant connection. The router has determined that this connection is redundant with another one.
+ 理由= 3：冗長接続。ルーターは、この接続が別の接続と重複していると判断しました。
+ Reason = 4: Session permanently administratively closed, will not be re-initiated. Monitoring station should reduce (potentially to 0) the rate at which it attempts reconnection to the monitored router.
+ 理由= 4：セッションは管理上完全に閉じられており、再開されません。監視ステーションは、監視対象ルーターへの再接続を試みる速度を（場合によっては0まで）下げる必要があります。
o Information Length (2 bytes): The length of the following Information field, in bytes.
o 情報の長さ（2バイト）：次の情報フィールドの長さ（バイト単位）。
o Information (variable): Information about the monitored router, according to the type.
o 情報（変数）：タイプに応じた、監視対象ルーターに関する情報。
Route Monitoring messages are used for initial synchronization of the ADJ-RIBs-In. They are also used for ongoing monitoring of the ADJ-RIB-In state. Route monitoring messages are state-compressed. This is all discussed in more detail in Section 5.
ルートモニタリングメッセージは、ADJ-RIBs-Inの初期同期に使用されます。これらは、ADJ-RIB-In状態の継続的な監視にも使用されます。ルートモニタリングメッセージは状態圧縮されます。これについては、セクション5で詳しく説明します。
Following the common BMP header and per-peer header is a BGP Update PDU.
共通のBMPヘッダーとピアごとのヘッダーに続いて、BGP更新PDUがあります。
Route Mirroring messages are used for verbatim duplication of messages as received. A possible use for mirroring is exact mirroring of one or more monitored BGP sessions, without state compression. Another possible use is the mirroring of messages that have been treated-as-withdraw [RFC7606], for debugging purposes. Mirrored messages may be sampled, or may be lossless. The Messages Lost Information code is provided to allow losses to be indicated. Section 6 provides more detail.
ルートミラーリングメッセージは、受信したメッセージを逐語的に複製するために使用されます。ミラーリングの可能な使用法は、状態圧縮なしで、1つ以上の監視対象BGPセッションの正確なミラーリングです。もう1つの可能な使用法は、デバッグの目的で、withdrawとして処理されたメッセージのミラーリング[RFC7606]です。ミラーリングされたメッセージは、サンプリングされる場合もあれば、ロスレスの場合もあります。メッセージ喪失情報コードは、喪失を示すことができるように提供されています。セクション6で詳細を説明します。
Following the common BMP header and per-peer header is a set of TLVs that contain information about a message or set of messages. Each TLV comprises a 2-byte type code, a 2-byte length field, and a variable-length value. Inclusion of any given TLV is OPTIONAL; however, at least one TLV SHOULD be included, otherwise there's no point in sending the message. Defined TLVs are as follows:
共通のBMPヘッダーとピアごとのヘッダーに続いて、メッセージまたはメッセージのセットに関する情報を含むTLVのセットがあります。各TLVは、2バイトのタイプコード、2バイトの長さフィールド、および可変長の値で構成されます。特定のTLVを含めることはオプションです。ただし、少なくとも1つのTLVを含める必要があります。そうでない場合、メッセージを送信しても意味がありません。定義されているTLVは次のとおりです。
o Type = 0: BGP Message. A BGP PDU. This PDU may or may not be an Update message. If the BGP Message TLV occurs in the Route Mirroring message, it MUST occur last in the list of TLVs.
o タイプ= 0：BGPメッセージ。 BGP PDU。このPDUは、更新メッセージである場合とそうでない場合があります。 BGPメッセージTLVがルートミラーリングメッセージで発生する場合、それはTLVのリストの最後に発生する必要があります。
o Type = 1: Information. A 2-byte code that provides information about the mirrored message or message stream. Defined codes are:
o タイプ= 1：情報。ミラーリングされたメッセージまたはメッセージストリームに関する情報を提供する2バイトのコード。定義されているコードは次のとおりです。
* Code = 0: Errored PDU. The contained message was found to have some error that made it unusable, causing it to be treated-as-withdraw [RFC7606]. A BGP Message TLV MUST also occur in the TLV list.
* コード= 0：エラーのあるPDU。含まれているメッセージは、それを使用できなくするいくつかのエラーがあり、撤回として扱われる原因となっていることがわかりました[RFC7606]。 BGPメッセージTLVもTLVリストで発生する必要があります。
* Code = 1: Messages Lost. One or more messages may have been lost. This could occur, for example, if an implementation runs out of available buffer space to queue mirroring messages.
* コード= 1：メッセージが失われました。 1つ以上のメッセージが失われた可能性があります。これは、たとえば、実装がミラーリングメッセージをキューに入れるために利用可能なバッファ領域を使い果たした場合に発生する可能性があります。
A Route Mirroring message may be sent any time it would be legal to send a Route Monitoring message.
ルートミラーリングメッセージは、ルートモニタリングメッセージを送信することが合法なときにいつでも送信できます。
These messages contain information that could be used by the monitoring station to observe interesting events that occur on the router.
これらのメッセージには、監視ステーションがルーターで発生する興味深いイベントを監視するために使用できる情報が含まれています。
Transmission of SR messages could be timer triggered or event driven (for example, when a significant event occurs or a threshold is reached). This specification does not impose any timing restrictions on when and on what event these reports have to be transmitted. It is left to the implementation to determine transmission timings -- however, configuration control should be provided of the timer and/or threshold values. This document only specifies the form and content of SR messages.
SRメッセージの送信は、タイマートリガーまたはイベントドリブンである可能性があります（たとえば、重要なイベントが発生したときやしきい値に達したとき）。この仕様では、これらのレポートを送信する必要があるタイミングとイベントにタイミングの制限はありません。送信タイミングを決定するのは実装に任されています-ただし、タイマーやしきい値の構成制御を提供する必要があります。このドキュメントでは、SRメッセージの形式と内容のみを指定しています。
Following the common BMP header and per-peer header is a 4-byte field that indicates the number of counters in the stats message where each counter is encoded as a TLV.
共通のBMPヘッダーとピアごとのヘッダーに続くのは、各カウンターがTLVとしてエンコードされている統計メッセージ内のカウンターの数を示す4バイトのフィールドです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stats Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Each counter is encoded as follows:
各カウンターは次のようにエンコードされます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stat Type | Stat Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stat Data |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Stat Type (2 bytes): Defines the type of the statistic carried in the Stat Data field.
o 統計タイプ（2バイト）：統計データフィールドに含まれる統計のタイプを定義します。
o Stat Len (2 bytes): Defines the length of the Stat Data field.
o Stat Len（2バイト）：Stat Dataフィールドの長さを定義します。
This specification defines the following statistics. A BMP implementation MUST ignore unrecognized stat types on receipt, and likewise MUST ignore unexpected data in the Stat Data field.
この仕様では、次の統計を定義しています。 BMP実装は、受信時に認識されない統計タイプを無視する必要があり、同様に、統計データフィールドの予期しないデータを無視する必要があります。
Stats are either counters or gauges, defined as follows after the examples in Section 3.2.3.3 of [RFC1155] and Section 4 of [RFC2856], respectively:
統計はカウンターまたはゲージであり、それぞれ[RFC1155]のセクション3.2.3.3および[RFC2856]のセクション4の例の後に以下のように定義されています。
32-bit Counter: A non-negative integer that monotonically increases until it reaches a maximum value, when it wraps around and starts increasing again from 0. It has a maximum value of 2^32-1 (4294967295 decimal).
32ビットカウンター：循環して最大値に達するまで単調に増加する非負の整数。循環し、0から再び増加し始めます。最大値は2 ^ 32-1（10進数の4294967295）です。
64-bit Gauge: A non-negative integer that may increase or decrease, but shall never exceed a maximum value, nor fall below a minimum one. The maximum value cannot be greater than 2^64-1 (18446744073709551615 decimal), and the minimum value cannot be smaller than 0. The value has its maximum value whenever the information being modeled is greater than or equal to its maximum value, and has its minimum value whenever the information being modeled is smaller than or equal to its minimum value. If the information being modeled subsequently decreases below the maximum value (or increases above the minimum value), the 64-bit Gauge also decreases (or increases).
64ビットゲージ：増加または減少する可能性がありますが、最大値を超えたり、最小値を下回ったりしてはならない負でない整数。最大値は2 ^ 64-1（10進数で18446744073709551615）より大きくすることはできず、最小値は0より小さくすることはできません。モデル化される情報がその最大値以上であり、かつモデル化される情報が最小値以下の場合の最小値。モデル化される情報がその後最大値を下回る（または最小値を上回る）場合、64ビットゲージも減少（または増加）します。
o Stat Type = 0: (32-bit Counter) Number of prefixes rejected by inbound policy.
o Stat Type = 0：（32-bit Counter）インバウンドポリシーによって拒否されたプレフィックスの数。
o Stat Type = 1: (32-bit Counter) Number of (known) duplicate prefix advertisements.
o 統計タイプ= 1：（32ビットカウンター）（既知の）重複するプレフィックスアドバタイズメントの数。
o Stat Type = 2: (32-bit Counter) Number of (known) duplicate withdraws.
o Stat Type = 2：（32-bit Counter）（known）duplicate withdrawsの数。
o Stat Type = 3: (32-bit Counter) Number of updates invalidated due to CLUSTER_LIST loop.
o Stat Type = 3：（32-bit Counter）CLUSTER_LISTループのために無効にされた更新の数。
o Stat Type = 4: (32-bit Counter) Number of updates invalidated due to AS_PATH loop.
o Stat Type = 4：（32ビットカウンター）AS_PATHループのために無効にされた更新の数。
o Stat Type = 5: (32-bit Counter) Number of updates invalidated due to ORIGINATOR_ID.
o 統計タイプ= 5：（32ビットカウンター）ORIGINATOR_IDが原因で無効にされた更新の数。
o Stat Type = 6: (32-bit Counter) Number of updates invalidated due to AS_CONFED loop.
o 統計タイプ= 6：（32ビットカウンター）AS_CONFEDループのために無効にされた更新の数。
o Stat Type = 7: (64-bit Gauge) Number of routes in Adj-RIBs-In.
o Stat Type = 7：（64-bit Gauge）Adj-RIBs-Inのルート数。
o Stat Type = 8: (64-bit Gauge) Number of routes in Loc-RIB.
o Stat Type = 8：（64-bit Gauge）Loc-RIB内のルートの数。
o Stat Type = 9: Number of routes in per-AFI/SAFI Adj-RIB-In. The value is structured as: 2-byte Address Family Identifier (AFI), 1-byte Subsequent Address Family Identifier (SAFI), followed by a 64-bit Gauge.
o Stat Type = 9：AFI / SAFI Adj-RIB-Inごとのルート数。値は、2バイトのアドレスファミリ識別子（AFI）、1バイトの後続アドレスファミリ識別子（SAFI）、それに続く64ビットのゲージのように構成されています。
o Stat Type = 10: Number of routes in per-AFI/SAFI Loc-RIB. The value is structured as: 2-byte AFI, 1-byte SAFI, followed by a 64-bit Gauge.
o Stat Type = 10：AFI / SAFI Loc-RIBごとのルート数。値は、2バイトのAFI、1バイトのSAFI、64ビットのゲージの順に構成されています。
o Stat Type = 11: (32-bit Counter) Number of updates subjected to treat-as-withdraw treatment [RFC7606].
o 統計タイプ= 11：（32ビットカウンター）取り消しとして扱う処理を受けた更新の数[RFC7606]。
o Stat Type = 12: (32-bit Counter) Number of prefixes subjected to treat-as-withdraw treatment [RFC7606].
o 統計タイプ= 12：（32ビットカウンター）取り消しとして処理されるプレフィックスの数[RFC7606]。
o Stat Type = 13: (32-bit Counter) Number of duplicate update messages received.
o Stat Type = 13：（32-bit Counter）受信した重複更新メッセージの数。
Although the current specification only specifies 4-byte counters and 8-byte gauges as "Stat Data", this does not preclude future versions from incorporating more complex TLV-type "Stat Data" (for example, one that can carry prefix-specific data). SR messages are optional. However, if an SR message is transmitted, at least one statistic MUST be carried in it.
現在の仕様では4バイトのカウンターと8バイトのゲージのみが「Stat Data」として指定されていますが、これは将来のバージョンがより複雑なTLVタイプの「Stat Data」（たとえば、プレフィックス固有のデータを伝送できるもの）を組み込むことを排除するものではありません）。 SRメッセージはオプションです。ただし、SRメッセージが送信される場合は、少なくとも1つの統計値が含まれている必要があります。
This message is used to indicate that a peering session was terminated.
このメッセージは、ピアリングセッションが終了したことを示すために使用されます。
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
+-+-+-+-+-+-+-+-+
| Reason |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data (present if Reason = 1, 2 or 3) |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reason indicates why the session was closed. Defined values are:
理由は、セッションが閉じられた理由を示します。定義されている値は次のとおりです。
o Reason 1: The local system closed the session. Following the Reason is a BGP PDU containing a BGP NOTIFICATION message that would have been sent to the peer.
o 理由1：ローカルシステムがセッションを閉じました。理由に続いて、ピアに送信されるBGP NOTIFICATIONメッセージを含むBGP PDUがあります。
o Reason 2: The local system closed the session. No notification message was sent. Following the reason code is a 2-byte field containing the code corresponding to the Finite State Machine (FSM) Event that caused the system to close the session (see Section 8.1 of [RFC4271]). Two bytes both set to 0 are used to indicate that no relevant Event code is defined.
o 理由2：ローカルシステムがセッションを閉じました。通知メッセージは送信されませんでした。理由コードに続くのは、システムがセッションを閉じる原因となった有限状態機械（FSM）イベントに対応するコードを含む2バイトのフィールドです（[RFC4271]のセクション8.1を参照）。どちらも0に設定された2バイトは、関連するイベントコードが定義されていないことを示すために使用されます。
o Reason 3: The remote system closed the session with a notification message. Following the Reason is a BGP PDU containing the BGP NOTIFICATION message as received from the peer.
o 理由3：リモートシステムがセッションを閉じ、通知メッセージが表示されました。理由に続いて、ピアから受信したBGP NOTIFICATIONメッセージを含むBGP PDUがあります。
o Reason 4: The remote system closed the session without a notification message. This includes any unexpected termination of the transport session, so in some cases both the local and remote systems might consider this to apply.
o 理由4：リモートシステムが通知メッセージなしでセッションを閉じました。これには、トランスポートセッションの予期しない終了が含まれるため、場合によっては、ローカルシステムとリモートシステムの両方がこれを適用すると見なします。
o Reason 5: Information for this peer will no longer be sent to the monitoring station for configuration reasons. This does not, strictly speaking, indicate that the peer has gone down, but it does indicate that the monitoring station will not receive updates for the peer.
o 理由5：構成上の理由により、このピアの情報は監視ステーションに送信されなくなります。これは、厳密には、ピアがダウンしたことを示すものではありませんが、監視ステーションがピアの更新を受信しないことを示しています。
A Peer Down message implicitly withdraws all routes that were associated with the peer in question. A BMP implementation MAY omit sending explicit withdraws for such routes.
ピアダウンメッセージは、問題のピアに関連付けられていたすべてのルートを暗黙的に撤回します。 BMP実装は、そのようなルートの明示的な撤回の送信を省略してもよい（MAY）。
The Peer Up message is used to indicate that a peering session has come up (i.e., has transitioned into the Established state). Following the common BMP header and per-peer header is the following:
ピアアップメッセージは、ピアリングセッションが起動した（つまり、確立状態に移行した）ことを示すために使用されます。共通のBMPヘッダーとピアごとのヘッダーは次のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Address (16 bytes) |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Port | Remote Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sent OPEN Message |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Received OPEN Message |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Information (variable) |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Local Address: The local IP address associated with the peering TCP session. It is 4 bytes long if an IPv4 address is carried in this field, as determined by the V flag (with the 12 most significant bytes zero-filled) and 16 bytes long if an IPv6 address is carried in this field.
o ローカルアドレス：ピアリングTCPセッションに関連付けられたローカルIPアドレス。このフィールドにIPv4アドレスが含まれている場合、Vフラグ（最上位12バイトがゼロで埋められている）によって決定され、4バイト長であり、IPv6アドレスがこのフィールドに含まれている場合、16バイト長です。
o Local Port: The local port number associated with the peering TCP session, or 0 if no TCP session actually exists (see Section 8.2).
o ローカルポート：ピアリングTCPセッションに関連付けられたローカルポート番号、またはTCPセッションが実際に存在しない場合は0（セクション8.2を参照）。
o Remote Port: The remote port number associated with the peering TCP session, or 0 if no TCP session actually exists (see Section 8.2). (The remote address can be found in the Peer Address field of the fixed header.)
o リモートポート：ピアリングTCPセッションに関連付けられているリモートポート番号。TCPセッションが実際に存在しない場合は0（セクション8.2を参照）。 （リモートアドレスは、固定ヘッダーの[ピアアドレス]フィールドにあります。）
o Sent OPEN Message: The full OPEN message transmitted by the monitored router to its peer.
o 送信されたOPENメッセージ：監視対象ルーターからピアに送信された完全なOPENメッセージ。
o Received OPEN Message: The full OPEN message received by the monitored router from its peer.
o 受信したOPENメッセージ：監視対象ルーターがピアから受信した完全なOPENメッセージ。
o Information: Information about the peer, using the Information TLV (Section 4.4) format. Only the string type is defined in this context; it may be repeated. Inclusion of the Information field is OPTIONAL. Its presence or absence can be inferred by inspection of the Message Length in the common header.
o 情報：ピアに関する情報。情報TLV（セクション4.4）形式を使用します。このコンテキストでは、文字列タイプのみが定義されています。それは繰り返されるかもしれません。情報フィールドを含めることはオプションです。その存在または不在は、共通ヘッダーのメッセージ長の検査によって推測できます。
In BMP's normal operating mode, after the BMP session is up, Route Monitoring messages are used to provide a snapshot of the Adj-RIB-In of each monitored peer. This is done by sending all routes stored in the Adj-RIB-In of those peers using standard BGP Update messages, encapsulated in Route Monitoring messages. There is no requirement on the ordering of messages in the peer dumps. When the initial dump is completed for a given peer, this MUST be indicated by sending an End-of-RIB marker for that peer (as specified in Section 2 of [RFC4724], plus the BMP encapsulation header). See also Section 9.
BMPの通常の動作モードでは、BMPセッションが起動した後、ルートモニタリングメッセージを使用して、監視対象の各ピアのAdj-RIB-Inのスナップショットが提供されます。これは、ルートモニタリングメッセージにカプセル化された標準のBGPアップデートメッセージを使用して、これらのピアのAdj-RIB-Inに保存されているすべてのルートを送信することによって行われます。ピアダンプでのメッセージの順序に関する要件はありません。特定のピアの初期ダンプが完了したら、そのピアのEnd-of-RIBマーカー（[RFC4724]のセクション2で指定されているとおり）とBMPカプセル化ヘッダーを送信することで、これを示す必要があります。セクション9も参照してください。
A BMP speaker may send pre-policy routes, post-policy routes, or both. The selection may be due to implementation constraints (it is possible that a BGP implementation may not store, for example, routes that have been filtered out by policy). Pre-policy routes MUST have their L flag clear in the BMP header (see Section 4), post-policy routes MUST have their L flag set. When an implementation chooses to send both pre- and post-policy routes, it is effectively multiplexing two update streams onto the BMP session. The streams are distinguished by their L flags.
BMPスピーカーは、ポリシー前ルート、ポリシー後ルート、またはその両方を送信できます。選択は、実装の制約が原因である可能性があります（BGP実装が、たとえば、ポリシーによってフィルターで除外されたルートを格納しない可能性があります）。ポリシー前のルートはBMPヘッダー（セクション4を参照）でLフラグをクリアする必要があり、ポリシー後のルートはLフラグを設定する必要があります。実装がポリシー適用前ルートとポリシー適用後ルートの両方を送信することを選択した場合、2つの更新ストリームをBMPセッションに効果的に多重化します。ストリームは、Lフラグによって区別されます。
If the implementation is able to provide information about when routes were received, it MAY provide such information in the BMP Timestamp field. Otherwise, the BMP Timestamp field MUST be set to 0, indicating that time is not available.
ルートがいつ受信されたかに関する情報を実装が提供できる場合、そのような情報をBMPタイムスタンプフィールドに提供してもよい（MAY）。それ以外の場合は、BMPタイムスタンプフィールドを0に設定する必要があります。これは、時間が利用できないことを示します。
Ongoing monitoring is accomplished by propagating route changes in BGP Update PDUs and forwarding those PDUs to the monitoring station, again using RM messages. When a change occurs to a route, such as an attribute change, the router must update the monitoring station with the new attribute. As discussed above, it MAY generate either an update with the L flag clear, with it set, or two updates, one with the L flag clear and the other with the L flag set. When a route is withdrawn by a peer, a corresponding withdraw is sent to the monitoring station. The withdraw MUST have its L flag set to correspond to that of any previous announcement; if the route in question was previously announced with L flag both clear and set, the withdraw MUST similarly be sent twice, with L flag clear and set. Multiple changed routes MAY be grouped into a single BGP UPDATE PDU when feasible, exactly as in the standard BGP protocol.
継続的な監視は、BGP Update PDUでルート変更を伝播し、再びRMメッセージを使用して、それらのPDUを監視ステーションに転送することによって行われます。属性の変更など、ルートに変更が発生した場合、ルーターは監視ステーションを新しい属性で更新する必要があります。上記のように、Lフラグをクリアして更新を設定するか、LフラグをクリアしてLフラグを設定して2つの更新を生成する場合があります。ルートがピアによって撤回されると、対応する撤回が監視ステーションに送信されます。 withdrawのLフラグは、以前のアナウンスのLフラグに対応するように設定する必要があります。問題のルートが以前にLフラグがクリアおよび設定されてアナウンスされている場合、Lフラグがクリアおよび設定された状態でwithdrawを2回送信する必要があります。複数の変更されたルートは、標準のBGPプロトコルとまったく同じように、実行可能な場合は単一のBGP UPDATE PDUにグループ化できます。
It's important to note that RM messages are not replicated messages received from a peer. (Route mirroring (Section 6) is provided if this is required.) While the router should attempt to generate updates promptly, there is a finite time that could elapse between reception of an update, the generation an RM message, and its transmission to the monitoring station. If there are state changes in the interim for that prefix, it is acceptable that the router generate the final state of that prefix to the monitoring station. This is sometimes known as "state compression". The actual PDU generated and transmitted to the station might also differ from the exact PDU received from the peer, for example, due to differences between how different implementations format path attributes.
RMメッセージは、ピアから受信した複製メッセージではないことに注意することが重要です。 （これが必要な場合は、ルートミラーリング（セクション6）が提供されます。）ルーターは更新を迅速に生成しようとする必要がありますが、更新の受信、RMメッセージの生成、およびへの送信の間に一定の時間が経過する可能性があります。監視ステーション。そのプレフィックスの暫定的な状態変更がある場合、ルータがそのプレフィックスの最終状態を監視ステーションに生成することは許容されます。これは「状態圧縮」と呼ばれることもあります。生成されてステーションに送信される実際のPDUは、たとえば、実装がパス属性をフォーマットする方法の違いにより、ピアから受信した正確なPDUと異なる場合もあります。
Route Mirroring messages are provided for two primary reasons: First, to enable an implementation to operate in a mode where it provides a full-fidelity view of all messages received from its peers, without state compression. As we note in Section 5, BMP's normal operational mode cannot provide this. Implementors are strongly cautioned that without state compression, an implementation could require unbounded storage to buffer messages queued to be mirrored. Route Mirroring is unlikely to be suitable for implementation in conventional routers, and its use is NOT RECOMMENDED except in cases where implementors have carefully considered the tradeoffs. These tradeoffs include: router resource exhaustion, the potential to interfere with the transmission or reception of BGP UPDATE messages, and the slowing of routing convergence.
ルートミラーリングメッセージが提供される主な理由は2つあります。1つ目は、ピアから受信したすべてのメッセージを完全に忠実に表示するモードで実装を操作できるようにすることです。セクション5で説明したように、BMPの通常の操作モードではこれを提供できません。実装者は、状態の圧縮がない場合、ミラーリングするためにキューに入れられたメッセージをバッファリングするために、無制限のストレージが必要になる可能性があることを強く警告します。ルートミラーリングは、従来のルーターでの実装に適しているとは考えにくいため、実装者がトレードオフを慎重に検討した場合を除いて、その使用は推奨されません。これらのトレードオフには、ルーターリソースの枯渇、BGP UPDATEメッセージの送信または受信に干渉する可能性、ルーティングの収束の遅延などがあります。
The second application for Route Mirroring is for error reporting and diagnosis. When Revised Error Handling for BGP UPDATE messages [RFC7606] is in use, a router can process BGP messages that are determined to contain errors, without resetting the BGP session. Such messages MAY be mirrored. The buffering used for such mirroring SHOULD be limited. If an errored message is unable to be mirrored due to buffer exhaustion, a message with the "Messages Lost" code SHOULD be sent to indicate this. (This implies that a buffer should be reserved for this use.)
ルートミラーリングの2番目のアプリケーションは、エラーの報告と診断です。 BGP UPDATEメッセージの改訂エラー処理[RFC7606]を使用している場合、ルーターは、BGPセッションをリセットせずに、エラーが含まれていると判断されたBGPメッセージを処理できます。このようなメッセージはミラーリングされる場合があります。そのようなミラーリングに使用されるバッファリングは制限されるべきです（SHOULD）。エラーメッセージがバッファの枯渇のためにミラーリングできない場合は、「失われたメッセージ」コードを含むメッセージを送信してこれを示す必要があります（SHOULD）。 （これは、この用途のためにバッファーを予約する必要があることを意味します。）
As outlined above, SR messages are used to monitor specific events and counters on the monitored router. One type of monitoring could be to find out if there are an undue number of route advertisements and withdraws happening (churn) on the monitored router. Another metric is to evaluate the number of looped AS_PATHs on the router.
上記のように、SRメッセージは、監視対象ルーターの特定のイベントとカウンターを監視するために使用されます。監視の1つのタイプは、監視対象のルーターで過度の数のルートアドバタイズと撤退が発生（チャーン）しているかどうかを確認することです。別の測定基準は、ルーター上のループしたAS_PATHの数を評価することです。
While this document proposes a small set of counters to begin with, the authors envision that this list may grow in the future with new applications that require BMP-style monitoring.
このドキュメントでは、最初に少数のカウンターのセットを提案していますが、BMPスタイルの監視を必要とする新しいアプリケーションによって、このリストは将来的に増える可能性があると著者たちは想定しています。
Some routers may support multiple instances of the BGP protocol, for example, as "logical routers" or through some other facility. The BMP protocol relates to a single instance of BGP; thus, if a router supports multiple BGP instances it should also support multiple BMP instances (one per BGP instance). Different BMP instances SHOULD generate Initiation Messages that are distinct from one another, for example, by using distinguishable sysNames or by the inclusion of instance-identifying information in a string TLV.
一部のルーターは、BGPプロトコルの複数のインスタンスを、たとえば「論理ルーター」として、または他の機能を介してサポートする場合があります。 BMPプロトコルは、BGPの単一インスタンスに関連しています。したがって、ルーターが複数のBGPインスタンスをサポートする場合は、複数のBMPインスタンスもサポートする必要があります（BGPインスタンスごとに1つ）。異なるBMPインスタンスは、たとえば、区別可能なsysNamesを使用することによって、または文字列TLVにインスタンスを識別する情報を含めることによって、互いに異なる開始メッセージを生成する必要があります（SHOULD）。
Some consideration is required for routes originated into BGP by the local router, whether as a result of redistribution from another protocol or for some other reason.
別のプロトコルからの再配布の結果であるか、その他の理由であるかに関わらず、ローカルルータによってBGPに発信されたルートには、いくつかの考慮事項が必要です。
Such routes can be modeled as having been sent by the router to itself, placing the router's own address in the Peer Address field of the header. It is RECOMMENDED that when doing so, the router should use the same address it has used as its local address for the BMP session. Since in this case no transport session actually exists, the Local and Remote Port fields of the Peer Up message MUST be set to 0. Clearly, the OPEN Message fields of the Peer Up message will equally not have been transmitted physically, but should represent the relevant capabilities of the local router.
このようなルートは、ルーターからルーター自体に送信され、ルーターの独自のアドレスをヘッダーのピアアドレスフィールドに配置することでモデル化できます。その際、ルーターはBMPセッションのローカルアドレスとして使用したのと同じアドレスを使用することをお勧めします。この場合、トランスポートセッションは実際には存在しないため、ピアアップメッセージのローカルポートフィールドとリモートポートフィールドは0に設定する必要があります。明らかに、ピアアップメッセージのOPENメッセージフィールドは、物理的には同様に送信されませんが、ローカルルーターの関連機能。
Also, recall that the L flag is used to indicate locally sourced routes, see Section 4.2.
また、Lフラグはローカルでソースされたルートを示すために使用されることを思い出してください。セクション4.2を参照してください。
Once the BMP session is established, route monitoring starts dumping the current snapshot as well as incremental changes simultaneously.
BMPセッションが確立されると、ルートモニタリングは現在のスナップショットのダンプと増分変更のダンプを同時に開始します。
It is fine to have these operations occur concurrently. If the initial dump visits a route and subsequently a withdraw is received, this will be forwarded to the monitoring station that would have to correlate and reflect the deletion of that route in its internal state. This is an operation that a monitoring station would need to support, regardless.
これらの操作を同時に実行しても問題ありません。最初のダンプがルートを訪問し、その後撤回が受信された場合、これは監視ステーションに転送されます。監視ステーションは、そのルートの削除を内部状態に関連付けて反映する必要があります。これは、監視ステーションがサポートする必要がある操作です。
If the router receives a withdraw for a prefix even before the peer dump procedure visits that prefix, then the router would clean up that route from its internal state and will not forward it to the monitoring station. In this case, the monitoring station may receive a bogus withdraw it can safely ignore.
ピアダンププロシージャがプレフィックスにアクセスする前でも、ルーターがプレフィックスのwithdrawを受信した場合、ルーターはそのルートを内部状態からクリーンアップし、監視ステーションに転送しません。この場合、監視ステーションは、安全に無視できる偽の撤回を受け取る可能性があります。
IANA has created registries for the following BMP parameters, which are organized in a new group "BGP Monitoring Protocol (BMP) Parameters".
IANAは、新しいグループ「BGPモニタリングプロトコル（BMP）パラメータ」に編成された次のBMPパラメータのレジストリを作成しました。
This document defines seven message types for transferring BGP messages between cooperating systems (Section 4):
このドキュメントでは、協調システム間でBGPメッセージを転送するための7つのメッセージタイプを定義しています（セクション4）。
o Type 0: Route Monitoring o Type 1: Statistics Report o Type 2: Peer Down Notification o Type 3: Peer Up Notification o Type 4: Initiation o Type 5: Termination o Type 6: Route Mirroring
o タイプ0：ルートモニタリングoタイプ1：統計レポートoタイプ2：ピアダウン通知oタイプ3：ピアアップ通知oタイプ4：開始oタイプ5：終了oタイプ6：ルートミラーリング
Type values 0 through 127 MUST be assigned using the "Standards Action" policy, and values 128 through 250 using the "Specification Required" policy defined in [RFC5226]. Values 251 through 254 are Experimental, and value 255 is Reserved.
タイプ値0から127は、「標準アクション」ポリシーを使用して割り当てられなければならず、値128から250は、[RFC5226]で定義されている「必要な仕様」ポリシーを使用して割り当てられます。値251〜254は試験運用であり、値255は予約済みです。
This document defines three types of peers for purposes of interpreting the Peer Distinguisher field (Section 4.2):
このドキュメントでは、Peer Distinguisherフィールド（セクション4.2）を解釈するために、3種類のピアを定義しています。
o Peer Type = 0: Global Instance Peer o Peer Type = 1: RD Instance Peer o Peer Type = 2: Local Instance Peer
o ピアタイプ= 0：グローバルインスタンスピアoピアタイプ= 1：RDインスタンスピアoピアタイプ= 2：ローカルインスタンスピア
Peer Type values 0 through 127 MUST be assigned using the "Standards Action" policy, and values 128 through 250 using the "Specification Required" policy, defined in [RFC5226]. Values 251 through 254 are Experimental, and value 255 is Reserved.
ピアタイプ値0〜127は、「標準アクション」ポリシーを使用して割り当てられなければならず、値128〜250は、[RFC5226]で定義されている「仕様が必要」ポリシーを使用して割り当てられなければなりません。値251〜254は試験運用であり、値255は予約済みです。
This document defines three bit flags in the Peer Flags field of the per-peer header (Section 4.2). The bits are numbered from 0 (the high-order, or leftmost, bit) to 7 (the low-order, or rightmost, bit):
このドキュメントでは、ピアごとのヘッダー（セクション4.2）のピアフラグフィールドで3つのビットフラグを定義しています。ビットには、0（上位または左端のビット）から7（下位または右端のビット）までの番号が付けられています。
o Flag 0: V flag o Flag 1: L flag o Flag 2: A flag
o フラグ0：Vフラグoフラグ1：Lフラグoフラグ2：Aフラグ
Flags 3 through 7 are unassigned. The registration procedure for the registry is "Standards Action".
フラグ3〜7は割り当てられていません。レジストリの登録手順は「標準アクション」です。
This document defines fourteen statistics types for statistics reporting (Section 4.8):
このドキュメントでは、統計レポートの14の統計タイプを定義しています（セクション4.8）。
o Stat Type = 0: Number of prefixes rejected by inbound policy o Stat Type = 1: Number of (known) duplicate prefix advertisements o Stat Type = 2: Number of (known) duplicate withdraws o Stat Type = 3: Number of updates invalidated due to CLUSTER_LIST loop o Stat Type = 4: Number of updates invalidated due to AS_PATH loop o Stat Type = 5: Number of updates invalidated due to ORIGINATOR_ID o Stat Type = 6: Number of updates invalidated due to a loop found in AS_CONFED_SEQUENCE or AS_CONFED_SET o Stat Type = 7: Number of routes in Adj-RIBs-In o Stat Type = 8: Number of routes in Loc-RIB o Stat Type = 9: Number of routes in per-AFI/SAFI Adj-RIB-In o Stat Type = 10: Number of routes in per-AFI/SAFI Loc-RIB o Stat Type = 11: Number of updates subjected to treat-as-withdraw o Stat Type = 12: Number of prefixes subjected to treat-as-withdraw o Stat Type = 13: Number of duplicate update messages received
o Stat Type = 0：インバウンドポリシーによって拒否されたプレフィックスの数o Stat Type = 1：（既知の）重複するプレフィックスアドバタイズメントの数o Stat Type = 2：（既知の）重複する撤回の数o Stat Type = 3：期限切れの更新の数CLUSTER_LISTループへo Stat Type = 4：AS_PATHループにより無効にされた更新の数o Stat Type = 5：ORIGINATOR_IDにより無効にされた更新の数o Stat Type = 6：AS_CONFED_SEQUENCEまたはAS_CONFED_SETで検出されたループにより無効にされた更新の数o Stat Type = 7：Adj-RIBs-Inのルート数o Stat Type = 8：Loc-RIBのルート数o Stat Type = 9：AFI / SAFIごとのルート数Adj-RIB-In o Stat Type = 10：AFI / SAFI Loc-RIBごとのルート数o統計タイプ= 11：取り消しとして扱う更新の数o統計タイプ= 12：取り消しとして扱うプレフィックスの数o統計タイプ= 13：受信した重複更新メッセージの数
Stat Type values 0 through 32767 MUST be assigned using the "Standards Action" policy, and values 32768 through 65530 using the "Specification Required" policy, defined in [RFC5226]. Values 65531 through 65534 are Experimental, and value 65535 is Reserved.
[RFC5226]で定義されている「標準アクション」ポリシーを使用して統計タイプ値0〜32767を割り当て、「仕様が必要」ポリシーを使用して値32768〜65530を割り当てる必要があります。 65531から65534までの値は試験運用であり、65535は予約済みです。
This document defines three types for information carried in the Initiation message (Section 4.3):
このドキュメントでは、開始メッセージ（セクション4.3）で伝達される情報の3つのタイプを定義します。
o Type = 0: String o Type = 1: sysDescr o Type = 2: sysName
o タイプ= 0：文字列oタイプ= 1：sysDescr oタイプ= 2：sysName
Information type values 0 through 32767 MUST be assigned using the "Standards Action" policy, and values 32768 through 65530 using the "Specification Required" policy, defined in [RFC5226]. Values 65531 through 65534 are Experimental, and value 65535 is reserved.
情報タイプの値0〜32767は、「標準アクション」ポリシーを使用して割り当てられなければならず、値32768〜65530は、[RFC5226]で定義されている「仕様が必要」ポリシーを使用して割り当てられなければなりません。 65531から65534までの値は試験運用であり、65535は予約されています。
This document defines two types for information carried in the Termination message (Section 4.5):
このドキュメントでは、終了メッセージ（セクション4.5）で伝達される情報の2つのタイプを定義します。
o Type = 0: String o Type = 1: Reason
o タイプ= 0：文字列oタイプ= 1：理由
Information type values 0 through 32767 MUST be assigned using the "Standards Action" policy, and values 32768 through 65530 using the "Specification Required" policy, defined in [RFC5226]. Values 65531 through 65534 are Experimental, and value 65535 is Reserved.
情報タイプの値0〜32767は、「標準アクション」ポリシーを使用して割り当てられなければならず、値32768〜65530は、[RFC5226]で定義されている「仕様が必要」ポリシーを使用して割り当てられなければなりません。 65531から65534までの値は試験運用であり、65535は予約済みです。
This document defines five types for information carried in the Termination message (Section 4.5) Reason code:
このドキュメントでは、終了メッセージ（セクション4.5）理由コードで伝えられる情報の5つのタイプを定義します。
o Type = 0: Administratively closed o Type = 1: Unspecified reason o Type = 2: Out of resources o Type = 3: Redundant connection o Type = 4: Permanently administratively closed
o タイプ= 0：管理上クローズoタイプ= 1：不特定の理由oタイプ= 2：リソース不足oタイプ= 3：冗長接続oタイプ= 4：完全に管理上クローズ
Information type values 0 through 32767 MUST be assigned using the "Standards Action" policy, and values 32768 through 65530 using the "Specification Required" policy, defined in [RFC5226]. Values 65531 through 65534 are Experimental, and value 65535 is Reserved.
情報タイプの値0〜32767は、「標準アクション」ポリシーを使用して割り当てられなければならず、値32768〜65530は、[RFC5226]で定義されている「仕様が必要」ポリシーを使用して割り当てられなければなりません。 65531から65534までの値は試験運用であり、65535は予約済みです。
This document defines five types for information carried in the Peer Down Notification (Section 4.9) Reason code (and reserves one further type):
このドキュメントでは、Peer Down Notification（Section 4.9）Reasonコードで伝達される情報の5つのタイプを定義しています（さらに1つのタイプを予約しています）。
o Type = 0 is Reserved. o Type = 1: Local system closed, NOTIFICATION PDU follows o Type = 2: Local system closed, FSM Event follows o Type = 3: Remote system closed, NOTIFICATION PDU follows o Type = 4: Remote system closed, no data o Type = 5: Peer de-configured
o タイプ= 0は予約済みです。 oタイプ= 1：ローカルシステムクローズ、NOTIFICATION PDUが続くoタイプ= 2：ローカルシステムクローズ、FSMイベントが続くoタイプ= 3：リモートシステムクローズ、NOTIFICATION PDUが続くoタイプ= 4：リモートシステムクローズ、データなしoタイプ= 5：ピアの構成解除
Information type values 0 through 32767 MUST be assigned using the "Standards Action" policy, and values 32768 through 65530 using the "Specification Required" policy, defined in [RFC5226]. Values 65531 through 65534 are Experimental, and values 0 and 65535 are Reserved.
情報タイプの値0〜32767は、「標準アクション」ポリシーを使用して割り当てられなければならず、値32768〜65530は、[RFC5226]で定義されている「仕様が必要」ポリシーを使用して割り当てられなければなりません。 65531から65534までの値は試験運用であり、値0および65535は予約済みです。
This document defines two types for information carried in the Route Mirroring message (Section 4.7):
このドキュメントでは、ルートミラーリングメッセージ（セクション4.7）で伝達される情報の2つのタイプを定義します。
o Type = 0: BGP Message o Type = 1: Information
o タイプ= 0：BGPメッセージoタイプ= 1：情報
Information type values 0 through 32767 MUST be assigned using the "Standards Action" policy, and values 32768 through 65530 using the "Specification Required" policy, defined in [RFC5226]. Values 65531 through 65534 are Experimental, and value 65535 is Reserved.
情報タイプの値0〜32767は、「標準アクション」ポリシーを使用して割り当てられなければならず、値32768〜65530は、[RFC5226]で定義されている「仕様が必要」ポリシーを使用して割り当てられなければなりません。 65531から65534までの値は試験運用であり、65535は予約済みです。
This document defines two types for information carried in the Route Mirroring Information (Section 4.7) code:
このドキュメントでは、ルートミラーリング情報（セクション4.7）コードで伝達される情報の2つのタイプを定義します。
o Type = 0: Errored PDU o Type = 1: Messages Lost
o タイプ= 0：エラーのあるPDU oタイプ= 1：メッセージが失われた
Information type values 0 through 32767 MUST be assigned using the "Standards Action" policy, and values 32768 through 65530 using the "Specification Required" policy, defined in [RFC5226]. Values 65531 through 65534 are Experimental, and value 65535 is Reserved.
情報タイプの値0〜32767は、「標準アクション」ポリシーを使用して割り当てられなければならず、値32768〜65530は、[RFC5226]で定義されている「仕様が必要」ポリシーを使用して割り当てられなければなりません。 65531から65534までの値は試験運用であり、65535は予約済みです。
This document defines a mechanism to obtain a full dump or provide continuous monitoring of a BGP speaker's BGP routes, including received BGP messages. This capability could allow an outside party to obtain information not otherwise obtainable. For example, although it's hard to consider the content of BGP routes in the public Internet to be confidential, BGP is used in private contexts as well, for example, for L3VPN [RFC4364]. As another example, a clever attacker might be able to infer the content of the monitored router's import policy by comparing the pre-policy routes exposed by BMP, to post-policy routes exported in BGP.
このドキュメントでは、フルダンプを取得するメカニズム、または受信したBGPメッセージを含むBGPスピーカーのBGPルートを継続的に監視するメカニズムを定義します。この機能により、外部の当事者は、他の方法では取得できない情報を取得できる可能性があります。たとえば、パブリックインターネットのBGPルートの内容を機密であると見なすことは困難ですが、BGPはプライベートコンテキスト、たとえばL3VPN [RFC4364]でも使用されます。別の例として、巧妙な攻撃者は、BMPによって公開されたポリシー前ルートをBGPでエクスポートされたポリシー後ルートと比較することにより、監視対象ルーターのインポートポリシーの内容を推測できる可能性があります。
Implementations of this protocol SHOULD require manual configuration of the monitored and monitoring devices.
このプロトコルの実装では、監視対象デバイスと監視デバイスを手動で構成する必要があります（SHOULD）。
Unless a transport that provides mutual authentication is used, an attacker could masquerade as the monitored router and trick a monitoring station into accepting false information, or they could masquerade as a monitoring station and gain unauthorized access to BMP data. Unless a transport that provides confidentiality is used, a passive or active attacker could gain access to, or tamper with, the BMP data in flight.
相互認証を提供するトランスポートが使用されていない限り、攻撃者は監視対象のルーターになりすまして監視ステーションを騙し、誤った情報を受け入れたり、監視ステーションになりすましてBMPデータに不正アクセスしたりする可能性があります。機密性を提供するトランスポートを使用しない限り、パッシブまたはアクティブな攻撃者は、処理中のBMPデータにアクセスしたり、改ざんしたりする可能性があります。
Where the security considerations outlined above are a concern, users of this protocol should use IPsec [RFC4303] in tunnel mode with pre-shared keys.
上記で概説したセキュリティの考慮事項が懸念される場合、このプロトコルのユーザーは、事前共有キーを使用したトンネルモードでIPsec [RFC4303]を使用する必要があります。
[RFC1213] McCloghrie, K. and M. Rose, "Management Information Base for Network Management of TCP/IP-based internets: MIB-II", STD 17, RFC 1213, DOI 10.17487/RFC1213, March 1991, <http://www.rfc-editor.org/info/rfc1213>.
[RFC1213] McCloghrie、K。およびM. Rose、「TCP / IPベースのインターネットのネットワーク管理の管理情報ベース：MIB-II」、STD 17、RFC 1213、DOI 10.17487 / RFC1213、1991年3月、<http：/ /www.rfc-editor.org/info/rfc1213>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006, <http://www.rfc-editor.org/info/rfc4271>.
[RFC4271] Rekhter、Y。、編、Li、T。、編、S。Hares、編、「A Border Gateway Protocol 4（BGP-4）」、RFC 4271、DOI 10.17487 / RFC4271、2006年1月、<http://www.rfc-editor.org/info/rfc4271>。
[RFC4724] Sangli, S., Chen, E., Fernando, R., Scudder, J., and Y. Rekhter, "Graceful Restart Mechanism for BGP", RFC 4724, DOI 10.17487/RFC4724, January 2007, <http://www.rfc-editor.org/info/rfc4724>.
[RFC4724] Sangli、S.、Chen、E.、Fernando、R.、Scudder、J。、およびY. Rekhter、「BGPのグレースフルリスタートメカニズム」、RFC 4724、DOI 10.17487 / RFC4724、2007年1月、<http： //www.rfc-editor.org/info/rfc4724>。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、DOI 10.17487 / RFC5226、2008年5月、<http://www.rfc-editor.org / info / rfc5226>。
[RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet Autonomous System (AS) Number Space", RFC 6793, DOI 10.17487/RFC6793, December 2012, <http://www.rfc-editor.org/info/rfc6793>.
[RFC6793] Vohra、Q。およびE. Chen、「BGP Support for Four-Octet Autonomous System（AS）Number Space」、RFC 6793、DOI 10.17487 / RFC6793、2012年12月、<http：//www.rfc-editor。 org / info / rfc6793>。
[RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. Patel, "Revised Error Handling for BGP UPDATE Messages", RFC 7606, DOI 10.17487/RFC7606, August 2015, <http://www.rfc-editor.org/info/rfc7606>.
[RFC7606] Chen、E。、編、Scudder、J。、編、Mohapatra、P。、およびK. Patel、「BGP UPDATEメッセージのエラー処理の改訂版」、RFC 7606、DOI 10.17487 / RFC7606、2015年8月、 <http://www.rfc-editor.org/info/rfc7606>。
[RFC1155] Rose, M. and K. McCloghrie, "Structure and identification of management information for TCP/IP-based internets", STD 16, RFC 1155, DOI 10.17487/RFC1155, May 1990, <http://www.rfc-editor.org/info/rfc1155>.
[RFC1155] Rose、M。、およびK. McCloghrie、「TCP / IPベースのインターネットの管理情報の構造と識別」、STD 16、RFC 1155、DOI 10.17487 / RFC1155、1990年5月、<http：//www.rfc -editor.org/info/rfc1155>。
[RFC2856] Bierman, A., McCloghrie, K., and R. Presuhn, "Textual Conventions for Additional High Capacity Data Types", RFC 2856, DOI 10.17487/RFC2856, June 2000, <http://www.rfc-editor.org/info/rfc2856>.
[RFC2856] Bierman、A.、McCloghrie、K。、およびR. Presuhn、「追加の大容量データタイプのテキスト表記法」、RFC 2856、DOI 10.17487 / RFC2856、2000年6月、<http：//www.rfc-editor .org / info / rfc2856>。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, DOI 10.17487/RFC4303, December 2005, <http://www.rfc-editor.org/info/rfc4303>.
[RFC4303]ケント、S。、「IPカプセル化セキュリティペイロード（ESP）」、RFC 4303、DOI 10.17487 / RFC4303、2005年12月、<http://www.rfc-editor.org/info/rfc4303>。
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 2006, <http://www.rfc-editor.org/info/rfc4364>.
[RFC4364] Rosen、E。およびY. Rekhter、「BGP / MPLS IP Virtual Private Networks（VPNs）」、RFC 4364、DOI 10.17487 / RFC4364、2006年2月、<http://www.rfc-editor.org/info / rfc4364>。
Acknowledgements
謝辞
Thanks to Ebben Aries, Michael Axelrod, Serpil Bayraktar, Tim Evens, Pierre Francois, Jeffrey Haas, John Ioannidis, John Kemp, Mack McBride, Danny McPherson, David Meyer, Dimitri Papadimitriou, Tom Petch, Robert Raszuk, Erik Romijn, Peter Schoenmaker, and the members of the GROW working group for their comments.
エベン・アリース、マイケル・アクセルロッド、セルピル・バイラクタール、ティム・イブンズ、ピエール・フランソワ、ジェフリー・ハース、ジョン・イオアニディス、ジョン・ケンプ、マック・マクブライド、ダニー・マクファーソン、デビッド・マイヤー、ディミトリ・パパディミトリウ、トム・ペッチ、ロバート・ラスズク、エリック・ロミジン、ピーター・ショーケンメーカーとコメントのためのGROWワーキンググループのメンバー。
Authors' Addresses
著者のアドレス
John Scudder (editor) Juniper Networks 1194 N. Mathilda Ave. Sunnyvale, CA 94089 United States
John Scudder（編集者）Juniper Networks 1194 N. Mathilda Ave. Sunnyvale、CA 94089アメリカ合衆国
Email: jgs@juniper.net
Rex Fernando Cisco Systems 170 W. Tasman Dr. San Jose, CA 95134 United States
Rex Fernando Cisco Systems 170 W. Tasman Dr. San Jose、CA 95134アメリカ合衆国
Email: rex@cisco.com
Stephen Stuart Google 1600 Amphitheatre Parkway Mountain View, CA 94043 United States
Stephen Stuart Google 1600 Amphitheatre Parkway Mountain View、CA 94043アメリカ合衆国
Email: sstuart@google.com