One document matched: draft-ietf-grow-bmp-06.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC2119 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC4303 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.4303.xml">
<!ENTITY RFC5226 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.5226.xml">
<!ENTITY RFC2629 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml">
<!ENTITY RFC4271 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.4271.xml">
<!ENTITY RFC4893 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.4893.xml">
<!ENTITY RFC4724 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.4724.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that
most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="std" docName="draft-ietf-grow-bmp-06"
ipr="pre5378Trust200902">
<!-- category values: std, bcp, info, exp, and historic
ipr values: full3667, noModification3667, noDerivatives3667
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<title abbrev="BGP Monitoring Protocol">
BGP Monitoring Protocol</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<!-- Another author who claims to be an editor -->
<author fullname="John Scudder" initials="J.S."
surname="Scudder">
<organization>Juniper Networks</organization>
<address>
<postal>
<street>1194 N. Mathilda Ave</street>
<!-- Reorder these if your country does things differently -->
<city>Sunnyvale</city>
<region>CA</region>
<code>94089</code>
<country>USA</country>
</postal>
<email>jgs@juniper.net</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Rex Fernando" initials="R.F."
surname="Fernando">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>170 W. Tasman Dr.</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>USA</country>
</postal>
<email>rex@cisco.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Stephen Stuart" initials="S.S."
surname="Stuart">
<organization>Google</organization>
<address>
<postal>
<street>1600 Amphitheatre Parkway</street>
<!-- Reorder these if your country does things differently -->
<city>Mountain View</city>
<region>CA</region>
<code>94043</code>
<country>USA</country>
</postal>
<email>sstuart@google.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<date year="2011" />
<!-- Meta-data Declarations -->
<area>General</area>
<workgroup>Network Working Group</workgroup>
<keyword>IDR</keyword>
<keyword>BGP</keyword>
<keyword>GROW</keyword>
<keyword>BMP</keyword>
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<abstract>
<t>
This document proposes a simple protocol, BMP, which can be used to
monitor BGP sessions. BMP is intended to provide a more convenient
interface for obtaining route views for research purpose than the
screen-scraping approach in common use today. 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.
</t>
</abstract>
</front>
<middle>
<section anchor="Introduction" title="Introduction">
<t>
Many researchers wish to have access to the contents of routers'
BGP RIBs as well as a view of protocol updates that the router is
receiving. This monitoring task cannot be realized by standard
protocol mechanisms. At present, this data can only be obtained
through screen-scraping.
</t>
<t>
The BMP protocol provides access to the Adj-RIB-In of a peer on an
ongoing basis and a periodic dump of certain statistics that the
monitoring station can use for further analysis. The following
are the messages provided by BMP.
</t>
<t>
<list style="symbols">
<t>
Route Monitoring (RM): 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.
</t>
<t>
Peer Down Notification (PD): A message sent to indicate that a
peering session has gone down with information indicating the
reason for the session disconnect.
</t>
<t>
Stats Reports (SR): This is 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.
</t>
<t>
Peer Up Notification (PU): 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 ESTABLISHED state, a Peer Up Notification is sent for
each peer that is in ESTABLISHED state when the BMP session
itself comes up.
</t>
</list>
</t>
<t>
BMP operates over TCP. All options are controlled by configuration
on the monitored router. No 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 (e.g. by
half-closing the TCP session or setting its window size to zero) or
it MAY silently discard any data erroneously sent by the monitoring
station.
</t>
<t>
The monitoring station is configured to listen on a particular TCP
port and the router is configured to establish an active connection
to that port and to send messages on that TCP connection. There is
no initialization or handshaking phase, messages are simply sent as
soon as the connection is established. If the router is unable to
connect to the monitoring station, it periodically retries the
connection. A suggested default retry period is 30 seconds.
</t>
<t>
If the monitoring station intends to restart BMP processing, it
simply drops the connection. The router then re-establishes the
connection and resends the messages.
</t>
<section title="Requirements Language">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref
target="RFC2119">RFC 2119</xref>.</t>
</section>
</section> <!-- for Introductions section -->
<section title="Lifecycle of a BMP Session">
<t>
A BMP session begins when a router running BMP successfully opens a TCP
session (the "BMP session") to the monitoring station it is configured
to talk to. It MAY first send an Initiation message. It subsequently
sends a Peer Up message over the BMP session for each of its BGP peers
which are in Established state. It follows by sending the contents of
its Adj-RIBs-In (or Loc-RIB, see <xref
target="route_monitoring"></xref>) encapsulated in Route Monitoring
messages. Once it has sent all the routes for a given peer, it sends an
End-of-RIB message for that peer; when End-of-RIB has been sent for each
peer, the initial table dump has completed. (A monitoring station that
wishes only 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.)
</t>
<t>
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 BGP peers become Established, corresponding
Peer Up messages are sent. If any BGP peers for which Peer Up messages
were sent transition out of the Established state, corresponding Peer
Down messages are sent.
</t>
<t>
A BMP session ends when the TCP session that carries it is closed for
any reason.
</t>
</section>
<section title="BMP Message Format" anchor="bmp_message_format">
<section title="Common Header" anchor="common_header">
<t>
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.
</t>
<figure align="center">
<artwork align="center"><![CDATA[
0 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8
+-+-+-+-+-+-+-+-+
| Version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Msg. Type |
+---------------+
]]></artwork>
</figure>
<t>
<list style="symbols">
<t>
Version (1 byte): Indicates the BMP version. This is set to '3'
for all messages defined in this specification. Version 0 is
reserved and MUST NOT be sent.
</t>
<t>
Message Length (4 bytes): Length of the message in bytes (including
headers, data and encapsulated messages, if any).
</t>
<t>
Message Type (1 byte): This identifies the type of the BMP
message. A BMP implementation MUST ignore unrecognized message types
upon receipt.
<list style="symbols">
<t>
Type = 0: Route Monitoring
</t>
<?rfc subcompact="yes" ?>
<t>
Type = 1: Statistics Report
</t>
<t>
Type = 2: Peer Down Notification
</t>
<t>
Type = 3: Peer Up Notification
</t>
<t>
Type = 4: Initiation Message
</t>
</list>
<?rfc subcompact="no" ?>
</t>
</list>
</t>
</section>
<section title="Per-Peer Header" anchor="per_peer_header">
<t>
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.
</t>
<figure align="center">
<artwork align="center"><![CDATA[
0 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer Type | Peer Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer Distinguisher (present based on peer type) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer Address (16 bytes) |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer AS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer BGP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp (seconds) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp (microseconds) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>
<list style="symbols">
<t>
Peer Type (1 byte): These bits identify the type of the
peer. Currently only two types of peers are identified,
<list style="symbols">
<t>
Peer Type = 0: Global Instance Peer
</t>
<?rfc subcompact="yes" ?>
<t>
Peer Type = 1: L3 VPN Instance Peer
</t>
</list>
<?rfc subcompact="no" ?>
</t>
<t>
Peer Flags (1 byte): These flags provide more information about
the peer. The flags are defined as follows.
</t>
</list>
</t>
<t>
<figure align="center">
<artwork align="center"><![CDATA[
0 1 2 3 4 5 6 7 8
+-+-+-+-+-+-+-+-+
|V|L| Reserved |
+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
</t>
<?rfc subcompact="yes" ?>
<t>
<list style="empty">
<t>
<list style="symbols">
<t>
The V flag indicates the the Peer address is an IPv6 address.
For IPv4 peers this is set to 0.
</t>
<t>
The L flag, if set to 1, indicates that the message reflects the
Loc-RIB (i.e., it reflects the application of inbound policy).
It is set to 0 if the message reflects the Adj-RIB-In. See
<xref target="route_monitoring"></xref> for further detail.
</t>
<t>
The remaining bits are reserved for future use.
</t>
</list>
<?rfc subcompact="no" ?>
</t>
</list>
</t>
<t>
<list style="symbols">
<t>
Peer Distinguisher (8 bytes): Routers today can have multiple
instances (example L3VPNs). This field is present to distinguish
peers that belong to one address domain from the other.
<vspace blankLines="1"/>
If the peer is a "Global Instance Peer", this field is zero
filled. If the peer is a "L3VPN Instance Peer", it is set to the
route distinguisher of the particular L3VPN instance that the
peer belongs to.
</t>
<t>
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 most
significant bytes zero filled) and 16 bytes long if an IPv6
address is carried in this field.
</t>
<t>
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 <xref target="RFC4893"></xref>, it should be padded
with zeroes in the most significant bits.
</t>
<t>
Peer BGP ID: The BGP Identifier of the peer from which the
encapsulated PDU was received.
</t>
<t>
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.
</t>
</list>
</t>
</section>
<section title="Initiation Message" anchor="initiation">
<t>
The initiation message provides a means for the monitored router
to inform the monitoring station of its vendor, software version,
and so on. The initiation message is OPTIONAL. When used, 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.
</t>
<t>
The initiation message consists of the common BMP header followed
by one or more TLVs containing information about the monitored
router, as follows:
</t>
<figure align="center">
<artwork align="center"><![CDATA[
0 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Information Type | Information Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Information (variable) |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>
<list style="symbols">
<t>
Information Type (2 bytes): Type of information provided.
Defined types are:
<list style="symbols">
<t>
Type = 0: String. The Information field contains a free-form
UTF-8 string whose length is given by the "Information Length"
field.
</t>
</list>
</t>
<t>
Information Length (2 bytes): The length of the following
Information field, in bytes.
</t>
<t>
Information (variable): Information about the monitored
router, according to the type.
</t>
</list>
</t>
</section>
<section title="Route Monitoring" anchor="route_monitoring_msg">
<t>
Route Monitoring messages are used for initial synchronization of
ADJ-RIB-In. They are also used for ongoing monitoring of received
advertisements and withdraws. This is discussed in more detail in
subsequent sections.
</t>
<t>
Following the common BMP header and per-peer header is a BGP PDU.
</t>
</section>
<section title="Stats Reports" anchor="stats_reports">
<t>
These messages contain information that could be used by the
monitoring station to observe interesting events that occur on the
router. 'Stats Report' messages have a message type of '3'.
</t>
<t>
The transmission of the 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.
</t>
<t>
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.
</t>
<figure align="center">
<artwork align="center"><![CDATA[
0 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stats Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>
Each counter is encoded as follows,
</t>
<figure align="center">
<artwork align="center"><![CDATA[
0 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stat Type | Stat Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stat Data |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>
<list style="symbols">
<t>
Stat Type (2 bytes): Defines the type of the statistic carried
in the "Stat Data" field.
</t>
<t>
Stat Len (2 bytes): Defines the length of the "Stat Data" Field.
</t>
</list>
</t>
<t>
This specification defines the following statistics. All statistics are
4-byte quantities and the stats data are counters. A BMP implementation
MUST ignore unrecognized stat types on receipt, and likewise MUST
ignore unexpected data in the Stat Data field.
</t>
<t>
<list style="symbols">
<t>
Stat Type = 0: Number of prefixes rejected by inbound policy.
</t>
<t>
Stat Type = 1: Number of (known) duplicate prefix advertisements.
</t>
<t>
Stat Type = 2: Number of (known) duplicate withdraws.
</t>
<t>
Stat Type = 3: Number of updates invalidated due to CLUSTER_LIST loop.
</t>
<t>
Stat Type = 4: Number of updates invalidated due to AS_PATH loop.
</t>
<t>
Stat Type = 5: Number of updates invalidated due to ORIGINATOR_ID.
</t>
<t>
Stat Type = 6: Number of updates invalidated due to AS_CONFED loop.
</t>
</list>
</t>
<t>
Note that the current specification only specifies 4-byte counters as "Stat
Data". This does not preclude future versions from incorporating more
complex TLV-type "Stat Data" (for example, one which can carry
prefix specific data). SR messages are optional. However if an SR
message is transmitted, this specification requires at least one statistic
to be carried in it.
</t>
</section>
<section title="Peer Down Notification" anchor="peer_down_notification">
<t>
This message is used to indicate that a peering session was
terminated. The type of this message is 4.
</t>
<figure align="center">
<artwork align="center"><![CDATA[
0 1 2 3 4 5 6 7 8
+-+-+-+-+-+-+-+-+
| Reason | 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data (present if Reason = 1, 2 or 3) |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>
Reason indicates why the session was closed. Defined values are:
</t>
<t>
<list style="symbols">
<t>
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.
</t>
<t>
Reason 2: The local system closed the session. No notification
message was sent. Following the reason code is a two-byte
field containing the code corresponding to the FSM Event
which caused the system to close the session (see Section 8.1
of <xref target="RFC4271"></xref>). Zero is used to indicate
that no relevant Event code is defined.
</t>
<t>
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.
</t>
<t>
Reason 4: The remote system closed the session without a
notification message.
</t>
</list>
</t>
</section>
<section title="Peer Up Notification" anchor="peer_up_notification">
<t>
The Peer Up message is used to indicate that a peering session has
come up (i.e., has transitioned into ESTABLISHED state). Following
the common BMP header and per-peer header is the following:
</t>
<figure align="center">
<artwork align="center"><![CDATA[
0 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Address (16 bytes) |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Port | Remote Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sent OPEN Message |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Received OPEN Message |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>
<list style="symbols">
<t>
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 most significant bytes
zero filled) and 16 bytes long if an IPv6 address is carried in
this field.
</t>
<t>
Local Port: The local port number associated with the peering TCP
session.
</t>
<t>
Remote Port: The remote port number associated with the peering TCP
session. (Note that the remote address can be found in the Peer
Address field of the fixed header.)
</t>
<t>
Sent OPEN Message: The full OPEN message transmitted by the
monitored router to its peer.
</t>
<t>
Received OPEN Message: The full OPEN message received by the
monitored router from its peer.
</t>
</list>
</t>
</section>
</section>
<section title="Route Monitoring" anchor="route_monitoring">
<t>
After the BMP session is up, Route Monitoring messages are used to
provide a snapshot of the Adj-RIB-In of a particular peer. This
is done by sending all routes stored in the Adj-RIB-In of that peer
using standard BGP Update messages. There is no requirement on the
ordering of messages in the peer dump. When the initial peer dump
is completed, this MUST be indicated by sending an End-of-RIB
marker (as specified in Section 2 of <xref target="RFC4724"></xref>,
plus the BMP encapsulation header).
</t>
<t>
Depending on the implementation or configuration, it may only be
possible to send the Loc-RIB (post-policy routes) instead of the
Adj-RIB-In. This is because it is possible that a BGP
implementation may not store, for example, routes which have been
filtered out by policy. If this is the case, the implementation
may send the Loc-RIB path that pertains to a particular peer in the
route monitor message. Such paths MUST have the L flag set in the
BMP header (see <xref target="bmp_message_format"></xref>).
</t>
<t>
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
zero, indicating that time is not available.
</t>
<t>
AS Numbers in the BMP UPDATE message MUST be sent as 4-octet
quantities, as described in <xref target="RFC4893"></xref>. This
affects the AS_PATH and AGGREGATOR path attributes. AS4_PATH or
AS4_AGGREGATOR path attributes MUST NOT be sent in a BMP UPDATE
message, as it makes no sense to do so.
</t>
<t>
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 monitor with the new attribute. When a route
is withdrawn by a peer, a corresponding withdraw is sent to
the monitor. Multiple changed routes MAY be grouped into a
single BGP UPDATE PDU when feasible, exactly as in the
standard BGP protocol.
</t>
<t>
It's important to note that RM messages are not real time replicated
messages received from a peer. While the router should attempt to
generate updates as soon as they are received there is a finite
time that could elapse between reception of an update and 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. 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.
</t>
</section>
<section title="Stat Reports" anchor="stat_reports">
<t>
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.
</t>
<t>
While this document proposes a small set of counters to begin with,
the authors envision this list may grow in the future with new
applications that require BMP style monitoring.
</t>
</section>
<section title="Other Considerations" anchor="other_considerations">
<t>
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 BMP instance).
</t>
</section>
<section title="Using BMP" anchor="using_bmp">
<t>
Once the BMP session is established route monitoring starts
dumping the current snapshot as well as incremental changes
simultaneously.
</t>
<t>
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 which
would have to correlate and reflect the deletion of that route in
its internal state. This is an operation a monitoring station
would need to support regardless.
</t>
<t>
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 which it can safely ignore.
</t>
</section>
<section title="IANA Considerations" anchor="iana_considerations">
<t>
This document defines five message types for transferring BGP messages
between cooperating systems (<xref target="bmp_message_format"></xref>):
</t>
<t>
<list style="symbols">
<t>
Type 0: Route Monitor
</t>
<?rfc subcompact="yes" ?>
<t>
Type 1: Statistics Report
</t>
<t>
Type 2: Peer Down Notification
</t>
<t>
Type 3: Peer Up Notification
</t>
<t>
Type 4: Initiation
</t>
<?rfc subcompact="no" ?>
</list>
</t>
<t>
Type values 5 through 128 MUST be assigned using the "Standards Action"
policy, and values 129 through 255 using the "Specification Required"
policy defined in <xref target="RFC5226"></xref>.
</t>
<t>
This document defines five statistics types for statistics reporting
(<xref target="stats_reports"></xref>):
</t>
<t>
<list style="symbols">
<t>
Stat Type = 0: Number of prefixes rejected by inbound policy.
</t>
<?rfc subcompact="yes" ?>
<t>
Stat Type = 1: Number of (known) duplicate prefix advertisements.
</t>
<t>
Stat Type = 2: Number of (known) duplicate withdraws.
</t>
<t>
Stat Type = 3: Number of updates invalidated due to CLUSTER_LIST loop.
</t>
<t>
Stat Type = 4: Number of updates invalidated due to AS_PATH loop.
</t>
<t>
Stat Type = 5: Number of updates invalidated due to ORIGINATOR_ID.
</t>
<t>
Stat Type = 6: Number of updates invalidated due to AS_CONFED loop.
</t>
<?rfc subcompact="no" ?>
</list>
</t>
<t>
Stat Type values 7 through 32767 MUST be assigned using the "Standards
Action" policy, and values 32768 through 65535 using the "Specification
Required" policy, defined in <xref target="RFC5226"></xref>.
</t>
<t>
This document defines one type for information carried in the Initiation
message (<xref target="initiation"></xref>):
</t>
<t>
<list style="symbols">
<t>
Type = 0: String.
</t>
</list>
</t>
<t>
Information type values 1 through 32767 MUST be assigned using the "Standards
Action" policy, and values 32768 through 65535 using the "Specification
Required" policy, defined in <xref target="RFC5226"></xref>.
</t>
</section>
<section title="Security Considerations" anchor="security_considerations">
<t>
This document defines a mechanism to obtain a full dump or provide
continuous monitoring of a BGP speaker's local BGP table, including
received BGP messages. This capability could allow an outside party
to obtain information not otherwise obtainable.
</t>
<t>
Implementations of this protocol MUST require manual configuration of
the monitored and monitoring devices.
</t>
<t>
Users of this protocol MAY use some type of secure transmission
mechanism, such as <xref target="RFC4303">IPSec</xref>, to transmit this data.
</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>
Thanks to John ji Ioannidis, Mack McBride, Danny McPherson,
Dimitri Papadimitriou, Erik Romijn, and the members of the
GROW working group for their comments.
</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<!-- References split into informative and normative -->
<!-- There are 2 ways to insert reference entries from the citation libraries:
1. define an ENTITY at the top, and use "ampersand character"RFC2629;
here (as shown)
2. simply use a PI
"less than character"?rfc include="reference.RFC.2119.xml"?> here
(for I-Ds:
include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")
Both are cited textually in the same manner: by using xref elements.
If you use the PI option, xml2rfc will, by default, try to find included
files in the same directory as the including file. You can also define
the XML_LIBRARY environment variable
with a value containing a set of directories to search. These can be
either in the local
filing system or remote ones accessed by http (http://domain/dir/... ).-->
<references title="Normative References">
<!--?rfc include=
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?-->
&RFC2119;
&RFC4271;
&RFC4893;
&RFC5226;
&RFC4724;
</references>
<references title="Informative References">
&RFC4303;
</references>
<section title="Changes Between BMP Versions 1 and 2">
<t><list style="symbols">
<t>
Added Peer Up Message
</t>
<?rfc subcompact="yes" ?>
<t>
Added L flag
</t>
<t>
Editorial changes
</t>
<?rfc subcompact="no" ?>
</list></t>
</section>
<section title="Changes Between BMP Versions 2 and 3">
<t><list style="symbols">
<t>
Added a 16-bit length field to the fixed header.
</t>
<?rfc subcompact="yes" ?>
<t>
Clarified error handling.
</t>
<t>
Added stat types 5 and 6 (number of updates invalidated due to
ORIGINATOR_ID and AS_CONFED, respectively).
</t>
<t>
For peer down messages, the relevant FSM event is to be sent in
type 2 messages.
</t>
<t>
Added local address and local and remote ports to the peer
up message.
</t>
<t>
Require End-of-RIB marker after initial dump.
</t>
<t>
Added Initiation message with string content.
</t>
<t>
Changed assignment policy for IANA registries.
</t>
<t>
Editorial changes.
</t>
<?rfc subcompact="no" ?>
</list></t>
</section>
<!-- Change Log
v00 2008-10-01 PM Initial version
v01 2008-10-25 PM Revised version to delete the extcomm section and add deployment section
v02 2008-10-26 jgs Overall revision
v03 2008-10-26 PM Added email addresses for contributors and formatted that section
-->
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 04:22:46 |