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
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监控协议（BMP），可用于监控BGP会话。BMP旨在为获取管线视图提供一个方便的界面。在引入BMP之前，屏幕抓取是获取此类视图最常用的方法。设计目标是保持BMP简单、有用、易于实现，并且对服务的影响最小。BMP不适合用作路由协议。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
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）的产品。它代表了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.
版权所有（c）2016 IETF信托基金和确定为文件作者的人员。版权所有。
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)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
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
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路由信息库（RIBs）的内容，以及路由器正在接收的协议更新视图。此监视任务无法通过标准协议机制实现。在引入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].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”应按照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 RIB包含未经处理的路由信息，该信息已由其对等方播发给本地BGP演讲者。”在本文档中，这也称为预策略Adj RIB。
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 Post Policy 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 Stats Reports（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 对等向上通知：发送一条消息，指示已启动对等会话。该消息包括关于对等方之间在其打开的消息中交换的数据的信息，以及关于对等TCP会话本身的信息。除了在对等机转换到已建立状态时发送外，当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.
路由器可由一个或多个监测站监测。对于每个（路由器和监控站）对，一方在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地址集。它应该限制允许从给定IP地址同时连接的数量。此限制的默认值应为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.
路由器（或管理站）可以实现检测冗余连接的逻辑，如果双方都被配置为活动的，则可能发生这种情况，并且可以选择终止冗余连接。为此目的定义了终止原因代码。
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.
路由器配置为与一个或多个监控站通话。可以将其配置为仅发送其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.)
当活动方（路由器或管理站，由配置决定）成功打开TCP会话（“BMP会话”）时，BMP会话开始。会话启动后，路由器开始发送BMP消息。它必须以发送启动消息开始。随后，它通过BMP会话为处于已建立状态的每个受监控BGP对等方发送对等向上消息。随后，它将其Adj RIB的内容发送到路由监视消息中封装的（pre-policy、post-policy或两者，请参见第5节）。一旦发送了给定对等方的所有路由，它必须为该对等方发送结束RIB消息；当为每个受监控的对等方发送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
在初始表转储之后，路由器发送封装在路由监视消息中的增量更新。根据配置，它可能会定期发送统计报告甚至新的启动消息。如果建立了任何新的受监控BGP对等点，则会发送相应的对等点向上消息。如果有BGP
peers for which Peer Up messages were sent transition out of the Established state, corresponding Peer Down messages are sent.
为其发送对等向上消息的对等方脱离已建立状态，则发送相应的对等向下消息。
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会话因任何原因关闭时，BMP会话结束。路由器可以在关闭会话之前发送终止消息。
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 |
+---------------+
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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字节）：标识对等类型。目前，确定了三种类型的对等点：
* 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|
+-+-+-+-+-+-+-+-+
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).
* 如果设置为1，则L标志表示消息反映了post策略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_路径格式格式化的。如果设置为0，则使用4字节AS_路径格式[RFC6793]对消息进行格式化。BMP扬声器可以选择传播从其对等方接收的AS_路径信息，也可以选择将所有AS_路径信息重新格式化为4字节格式，而不管它是如何从对等方接收的。在后一种情况下，不应在BMP更新消息中发送AS4_路径或AS4_聚合器路径属性。当与路由镜像消息一起使用时，此标志没有意义（第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]）。此字段用于区分属于一个地址域和另一个地址域的对等方。
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 对等地址：与TCP会话关联的远程IP地址，通过该会话接收封装的PDU。若在该字段中携带IPv4地址，则长度为4字节（12个最高有效字节为零），若在该字段中携带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标识符。
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 时间戳：自1970年1月1日（UTC）午夜（零小时）起，接收封装路由的时间（也可以将其视为安装在Adj RIB中的时间），以秒和微秒表示。如果为零，则时间不可用。时间戳的精度取决于实现。
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.
启动消息由公共BMP标头和两个或多个信息TLV（第4.4节）组成，其中包含有关受监控路由器的信息。必须发送sysDescr和sysName信息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) |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
* Type=0:String。信息字段包含一个自由格式的UTF-8字符串，其长度由信息长度字段给出。该值是通过管理方式分配的。不需要使用空字符（或任何其他特定字符）终止字符串——信息长度字段给出其终止符。如果包含多个字符串，则在报告它们时必须保留它们的顺序。
* 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.
* Type=1:sysDescr。信息字段包含一个ASCII字符串，其值必须设置为等于sysDescr MIB-II[RFC1213]对象的值。
* 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.
* Type=2:sysName。信息字段包含一个ASCII字符串，其值必须设置为等于sysName MIB-II[RFC1213]对象的值。
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标头和一个或多个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) |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
* Type=0:String。信息字段包含一个自由格式的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肋骨的初始同步。它们还用于状态下ADJ肋骨的持续监测。路由监视消息是状态压缩的。第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.
路由镜像消息用于在接收时逐字复制消息。镜像的一个可能用途是精确镜像一个或多个受监控的BGP会话，而不进行状态压缩。另一种可能的用途是镜像已被视为撤回[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是可选的；但是，至少应该包括一个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：消息丢失。一条或多条消息可能已丢失。例如，如果实现的可用缓冲区空间不足，无法对镜像消息进行排队，则可能会发生这种情况。
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头和每个对等头之后是一个4字节字段，指示stats消息中的计数器数量，其中每个计数器编码为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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stats Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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数据字段的长度。
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（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（18446744073709551615十进制），最小值不能小于0。每当被建模的信息大于或等于其最大值时，该值具有其最大值；每当被建模的信息小于或等于其最小值时，该值具有其最小值。如果随后被建模的信息减小到最大值以下（或增大到最小值以上），则64位仪表也会减小（或增大）。
o Stat Type = 0: (32-bit Counter) Number of prefixes rejected by inbound policy.
o Stat Type=0：（32位计数器）入站策略拒绝的前缀数。
o Stat Type = 1: (32-bit Counter) Number of (known) duplicate prefix advertisements.
o Stat Type=1：（32位计数器）重复前缀播发的（已知）数量。
o Stat Type = 2: (32-bit Counter) Number of (known) duplicate withdraws.
o Stat Type=2：（32位计数器）重复提取的次数（已知）。
o Stat Type = 3: (32-bit Counter) Number of updates invalidated due to CLUSTER_LIST loop.
o Stat Type=3：（32位计数器）由于群集列表循环而无效的更新数。
o Stat Type = 4: (32-bit Counter) Number of updates invalidated due to AS_PATH loop.
o Stat Type=4：（32位计数器）由于AS_路径循环而无效的更新数。
o Stat Type = 5: (32-bit Counter) Number of updates invalidated due to ORIGINATOR_ID.
o Stat Type=5：（32位计数器）由于发起人ID而无效的更新数。
o Stat Type = 6: (32-bit Counter) Number of updates invalidated due to AS_CONFED loop.
o Stat Type=6：（32位计数器）由于AS_CONFED循环而无效的更新数。
o Stat Type = 7: (64-bit Gauge) Number of routes in Adj-RIBs-In.
o Stat Type=7：（64位规格）中调整筋中的路由数。
o Stat Type = 8: (64-bit Gauge) Number of routes in Loc-RIB.
o Stat Type=8：（64位规格）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调整肋的路线数。该值的结构为：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 统计类型=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 Stat Type=11：（32位计数器）被视为撤回处理的更新数[RFC7606]。
o Stat Type = 12: (32-bit Counter) Number of prefixes subjected to treat-as-withdraw treatment [RFC7606].
o Stat Type=12：（32位计数器）被视为撤回处理的前缀数[RFC7606]。
o Stat Type = 13: (32-bit Counter) Number of duplicate update messages received.
o Stat Type=13：（32位计数器）接收到的重复更新消息数。
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字节仪表指定为“统计数据”，但这并不妨碍未来版本合并更复杂的TLV类型“统计数据”（例如，可携带前缀特定数据的数据）。SR消息是可选的。但是，如果传输SR消息，则其中必须至少包含一个统计信息。
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) |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 PDU包含本应发送给对等方的BGP通知消息。
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：本地系统关闭了会话。未发送任何通知消息。原因代码后面是一个2字节字段，其中包含导致系统关闭会话的有限状态机（FSM）事件对应的代码（请参阅[RFC4271]第8.1节）。两个都设置为0的字节用于指示未定义相关事件代码。
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 PDU包含从对等方接收的BGP通知消息。
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实现可能会忽略为此类路由发送显式取款。
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) |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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地址，则长度为4字节（由V标志确定）（12个最高有效字节为零填充），如果此字段中包含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 发送开放消息：受监控路由器向其对等方发送的完全开放消息。
o Received OPEN Message: The full OPEN message received by the monitored router from its peer.
o Received OPEN Message：受监控路由器从其对等方接收到的完全打开的消息。
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中的所有路由来完成的。对对等转储中的消息顺序没有要求。当给定对等体的初始转储完成时，必须通过发送该对等体的肋骨末端标记（如[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标头中清除其L标志（参见第4节），后策略路由必须设置其L标志。当一个实现选择发送前策略路由和后策略路由时，它实际上是将两个更新流多路复用到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时间戳字段中提供此类信息。否则，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标志。当对等方撤销路由时，将向监控站发送相应的撤销。撤回必须将其L标志设置为与任何先前公告的L标志相对应；如果所述路线之前在L标志清除和设置的情况下被宣布，则撤回同样必须在L标志清除和设置的情况下发送两次。在可行的情况下，可以将多个更改的路由分组到单个BGP更新PDU中，这与标准BGP协议完全相同。
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.
提供路由镜像消息有两个主要原因：第一，使实现能够在一种模式下运行，在这种模式下，它可以提供从其对等方接收的所有消息的完全保真度视图，而无需进行状态压缩。正如我们在第5节中所指出的，BMP的正常运行模式无法提供这一点。强烈提醒实现者，如果没有状态压缩，实现可能需要无限存储来缓冲排队等待镜像的消息。路由镜像不太可能适合在传统路由器中实现，除非实现者仔细考虑了权衡，否则不建议使用路由镜像。这些权衡包括：路由器资源耗尽、可能干扰BGP更新消息的传输或接收以及路由收敛的速度减慢。
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.)
路由镜像的第二个应用程序用于错误报告和诊断。当使用BGP更新消息[RFC7606]的修订错误处理时，路由器可以处理确定包含错误的BGP消息，而无需重置BGP会话。这样的消息可以被镜像。应限制用于此类镜像的缓冲。如果由于缓冲区耗尽而无法镜像出错的消息，则应发送带有“Messages Lost”（消息丢失）代码的消息以指示此情况。（这意味着应为此用途保留缓冲区。）
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消息用于监视受监视路由器上的特定事件和计数器。一种类型的监控可以是查明在被监控的路由器上是否有过多的路由广告和取款（搅动）。另一个指标是评估路由器上循环AS_路径的数量。
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实例一个）。不同的BMP实例应生成彼此不同的启动消息，例如，通过使用可区分的系统名或通过在字符串TLV中包含实例标识信息。
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。显然，对等向上消息的开放消息字段同样不会被物理传输，但应该表示本地路由器的相关功能。
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.
如果路由器甚至在对等转储过程访问前缀之前收到前缀的撤销，那么路由器将从其内部状态清除该路由，并且不会将其转发到监控站。在这种情况下，监测站可能会收到一个可以安全忽略的虚假撤回。
IANA has created registries for the following BMP parameters, which are organized in a new group "BGP Monitoring Protocol (BMP) Parameters".
IANA已经为以下BMP参数创建了注册表，这些参数被组织在一个新的组“BGP监控协议（BMP）参数”中。
This document defines seven message types for transferring BGP messages between cooperating systems (Section 4):
本文件定义了用于在协作系统之间传输BGP消息的七种消息类型（第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，使用[RFC5226]中定义的“所需规范”策略分配值128到250。值251到254为实验值，值255为保留值。
This document defines three types of peers for purposes of interpreting the Peer Distinguisher field (Section 4.2):
本文件定义了三种类型的对等体，用于解释对等体区分符字段（第4.2节）：
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，使用[RFC5226]中定义的“所需规范”策略分配值128到250。值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节）。位的编号从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):
本文件定义了统计报告的十四种统计类型（第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 统计类型=0：入站策略拒绝的前缀数o统计类型=1：重复前缀播发的（已知）数量o统计类型=2：重复前缀播发的（已知）数量重复提取o统计类型=3：由于群集\u列表循环o统计类型=4：由于AS\u路径循环o统计类型=5：由于发起者\u ID o统计类型=6：由于AS\u CONFED\u序列或AS\u CONFED\u集合o统计类型中发现的循环而无效的更新数量=7：o统计类型中的Adj RIB中的路由数=8：Loc RIB中的路由数o统计类型=9：每个AFI/SAFI Adj RIB中的路由数o统计类型=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.
统计类型值0到32767必须使用“标准操作”策略分配，值32768到65530必须使用[RFC5226]中定义的“所需规范”策略分配。65531到65534为实验值，65535为保留值。
This document defines three types for information carried in the Initiation message (Section 4.3):
本文件定义了三种类型的启动信息（第4.3节）：
o Type = 0: String o Type = 1: sysDescr o Type = 2: sysName
o 类型=0:String o Type=1:sysDescr o Type=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，使用[RFC5226]中定义的“所需规范”策略分配值32768到65530。65531到65534为实验值，65535为保留值。
This document defines two types for information carried in the Termination message (Section 4.5):
本文件定义了两种类型的终止信息（第4.5节）：
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，使用[RFC5226]中定义的“所需规范”策略分配值32768到65530。65531到65534为实验值，65535为保留值。
This document defines five types for information carried in the Termination message (Section 4.5) Reason code:
本文件定义了终止消息（第4.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，使用[RFC5226]中定义的“所需规范”策略分配值32768到65530。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):
本文件定义了对等停机通知（第4.9节）原因代码中包含的信息的五种类型（并保留另一种类型）：
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 Type=0是保留的。o类型=1：本地系统关闭，通知PDU遵循o类型=2：本地系统关闭，FSM事件遵循o类型=3：远程系统关闭，通知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，使用[RFC5226]中定义的“所需规范”策略分配值32768到65530。值65531到65534为实验值，值0和65535保留。
This document defines two types for information carried in the Route Mirroring message (Section 4.7):
本文件为路由镜像消息（第4.7节）中携带的信息定义了两种类型：
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，使用[RFC5226]中定义的“所需规范”策略分配值32768到65530。65531到65534为实验值，65535为保留值。
This document defines two types for information carried in the Route Mirroring Information (Section 4.7) code:
本文件定义了路由镜像信息（第4.7节）代码中包含的两种信息类型：
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，使用[RFC5226]中定义的“所需规范”策略分配值32768到65530。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 [RCF4364]。另一个例子是，聪明的攻击者可以通过比较BMP公开的策略前路由和BGP中导出的策略后路由来推断受监控路由器导入策略的内容。
Implementations of this protocol SHOULD require manual configuration of the monitored and monitoring devices.
本协议的实施应要求手动配置受监控设备和监控设备。
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.，Ed.，Li，T.，Ed.，和S.Hares，Ed.，“边境网关协议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，“在RFCs中编写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对四个八位组自治系统（AS）数字空间的支持”，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.，Ed.，Scudder，J.，Ed.，Mohapatra，P.，和K.Patel，“BGP更新消息的修订错误处理”，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.Presohn，“附加高容量数据类型的文本约定”，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]Kent，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虚拟专用网络（VPN）”，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.
感谢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和成长工作组成员的评论。
Authors' Addresses
作者地址
John Scudder (editor) Juniper Networks 1194 N. Mathilda Ave. Sunnyvale, CA 94089 United States
约翰·斯卡德尔（编辑）Juniper Networks 1194 N.Mathilda Ave.Sunnyvale，加利福尼亚州94089
Email: jgs@juniper.net
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.圣何塞，加利福尼亚州，美国95134
Email: rex@cisco.com
Email: rex@cisco.com
Stephen Stuart Google 1600 Amphitheatre Parkway Mountain View, CA 94043 United States
斯蒂芬·斯图亚特·谷歌1600圆形剧场公园道山景，美国加利福尼亚州94043
Email: sstuart@google.com
Email: sstuart@google.com