Definition for BMP Multiple Peer Header

Introduction defines the format of BMP messages including Initiation message, Termination message, Route Monitoring message, Route Mirroring message, Stats Reports message, and Peer Down/Up Notification message. Except Initiation and Termination message, all other BMP messages contain a Per-Peer Header. For BMP messages that include a Per-Peer Header, referred to as BMP Per-Peer message, a common format is defined as shown in .

Common Format of BMP Per-Peer Message Depending on the BMP message type in Common Header, the BMP TLV represents the corresponding BMP information. For multiple BMP Per-Peer messages, their BMP TLV may have both identical and differing parts. When transmitting BMP Per-Peer messages of the same type, these messages can be consolidated into a single message, retaining only one copy of the identical parts to reduce the message size, network overhead and improve overall network performance. This document defines a new BMP message type, referred to as Multi-Peer Header message. It can be used to compress multiple BMP messages of same type, each with a per-peer header, into a single aggregated BMP message, which could reduce the amount of reported BMP messages and reduce network overhead.

Requirements Language 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 BCP 14 when, and only when, they appear in all capitals, as shown here.

Multi-Peer Header Definition This section adds a new BMP message type for Multi-Peer Header, which is populated in the message type field of the Common Header. Message Type = TBD: Multi-Peer Header, Recommended value 7. The Multi-Peer Header mechanism defined in this document serves as a general framework for aggregating any BMP message type that includes a Per-Peer Header. While specific optimizations and detailed formats for particular message types (such as Statistics Reports) may be defined in future extensions, this document establishes the foundational structure that enables such optimizations.

Multi-Peer Header Message Format This section defines the BMP Multi-Peer Header message format, as shown in .

BMP Multi-Peer Header Message Format In the BMP Multi-Peer Header message format, the Common Header is the same as that defined in Section 4.1 of , the Common Multi-Peer Header carries the distinct Per-Peer Information of the corresponding BMP Per-Peer message, and the Common Information comprises the identical part of the corresponding BMP Per-Peer message. The Common Multi-Peer Header format is defined in Section 5. The Common Information format is defined differently based on various Message Types in the Common Multi-Peer Header.

Common Multi-Peer Header Format This section defines the format of the Common Multi-Peer Header in BMP Multi-Peer Header message, as shown in . The Multi-Peer Message Type maps to existing BMP message types that include a Per-Peer Header, as defined in (such as Route Monitoring, Peer Down Notification and Peer Up Notification). The Common Multi-Peer Header can be used to construct a BMP Multi-Peer Header message with various Multi-Peer Message Type. The Wild Card Per-Peer Header is defined below and is similar to the Per-Peer Header defined in Section 4.2 of . The Per-Peer Information is the different part of the corresponding BMP Per-Peer message.

Common Multi-Peer Header Format In the Common Multi-Peer Header format, The Multi-Peer Message Type definition is not included in this document, and it needs to be defined according to the specific application of BMP message type. The Multi-Peer Message Length is the length of Common Multi-Peer Header in bytes (including all Wild Card Per-Peer Headers, Per-Peer Information Lengths, and Per-Peer Information). The Per-Peer Information format can vary based on the various Multi-Peer Message Types. Each Wild Card Per-Peer Header could be followed by its unique/distinct Per-Peer Information corresponding the BMP Per-Peer Message. If no Per-Peer Information follows the Wild Card Per-Peer Header, the corresponding Per-Peer Information Length MUST be set to 0. This document defines an Wild Card Per-Peer Header, that could be used to apply to multiple peers, if desired. It is defined according to Per-Peer Header of , as shown in .

Wild Card Per-Peer Header Format Compared with Per-Peer Header define in Section 4.2 of , the Peer Mask is added to indicate the mask of Peer Address.

When Peer Mask is 32 for IPv4 and 128 for IPv6 - the Peer Address is used to indicate a specific peer (like the Peer Address of Per-Peer Header in RFC 7854).
When Peer Mask is 0 and Peer Address is 0 - the Wild Card Peer Header applies to for all peers.
Other non-zero values of Peer Mask - the Wild Card peer header applies to multiple peers matching 'peer address' AND 'peer mask' criteria.

Use Cases The Multi-Peer Header mechanism defined in this document is designed to optimize the transmission efficiency of BMP by aggregating messages that share common data across multiple peers. This section outlines several practical use cases where applying the Multi-Peer Header can significantly reduce network overhead and improve processing scalability at the monitoring station.

Aggregation of Peer Down Notifications In scenarios where a monitoring router experiences a common failure event (e.g., a link failure, maintenance action, or local software restart) that causes simultaneous BGP session discontinuities with multiple peers, multiple Peer Down Notification messages would typically be generated. These Peer Down Notification messages can be aggregated by using the Multi-Peer Header mechanism.

How it works: The Common Information section of the Multi-Peer Header Message would contain the common Reason code and any associated Reason TLVs (e.g., descriptive text) that apply to all affected sessions. Each distinct peer session is then represented by a Wild Card Per-Peer Header (with its specific Peer Address, AS, etc.) in the Common Multi-Peer Header. The Per-Peer Information for each may be empty or contain peer-specific details if needed.
Benefit: Instead of sending N individual Peer Down Notification messages (each with a full Per-Peer Header and repeated Reason information), a single aggregated message is transmitted. This drastically reduces the number of packets during failure storms, easing the load on the network and the collection system.

Optimized Route Monitoring and Route Mirroring for Common Updates Route Monitoring and Route Mirroring messages are the core BMP message types that carry actual BGP UPDATE message. When similar BGP UPDATE messages affect multiple peers, aggregation using the Multi-Peer Header mechanism can significantly improve efficiency.

How it works: The identical parts of BGP UPDATE PDUs (Protocol Data Unit) form the Common Information section. The Common Multi-Peer Header then lists the different parts of the set of peers (identified by their Wild Card Per-Peer Headers) associated with these BGP UPDATE PDUs.
Benefit: Avoids transmitting multiple similar copies of the same, potentially large, BGP UPDATE payload. This is particularly useful for recording widespread routing events or anomalies in a bandwidth-efficient manner.
Notes:
- Route Monitoring: This represents the most straightforward and efficient use case for aggregation. Since standard Route Monitoring messages primarily record which prefixes/paths were advertised or withdrawn by which peer, aggregation does not lose essential information.
- Route Mirroring: Implementers should be aware that this aggregation loses the precise temporal ordering and per-peer context that might be critical for some debugging purposes. Its use should be configurable and appropriate to the troubleshooting scenario.

Aggregation of Peer-up Notifications In scenarios where a monitoring router establishes BGP sessions with multiple peers that share common session parameters, Peer Up Notification messages can be efficiently aggregated using the Multi-Peer Header mechanism.

How it works: The 'Common Information' section would contain the shared parts of the Peer Up Notification, such as:
- Identical local and remote capabilities (if negotiated to be the same across peers)
- Any other TLVs that are identical across the peer sessions
Each distinct peer session is represented by a 'Wild Card Per-Peer Header' containing its specific addressing information (Peer Address, Peer AS, etc.). Peer-specific details, such as local address or unique TLVs, would be placed in the corresponding 'Per-Peer Information' section.
Benefit: When establishing sessions with a large group of similarly configured peers (e.g., route reflector clients or peers in a peer group), this aggregation avoids sending numerous nearly identical Peer Up Notification messages. This significantly reduces the initial message storm during network startup or maintenance operations.

Note: The effectiveness of this aggregation depends on the degree of commonality in session parameters. Peers within the same administrative group or those configured with identical templates are ideal candidates for this optimization.

Aggregation of Statistics Reports Statistics Reports messages, which convey various counter values per peer, can also benefit from the Multi-Peer Header mechanism, albeit with different trade-offs.

How it works: The 'Common Information' would typically contain only the Stat Type field (identifying which counter is being reported). The actual counter values, which are almost always peer-specific, are placed in the individual 'Per-Peer Information' sections along with their respective 'Wild Card Per-Peer Headers'.
Benefit: The primary optimization comes from header compression. Instead of sending N separate BMP messages (each with its own Common Header and Per-Peer Header), a single aggregated message carries one Common Header and multiple concise Per-Peer entries. This reduces:
- Network packet count (from N to 1)
- Processing overhead at both sender and receiver for handling multiple message headers
- Total bandwidth consumption by eliminating redundant header fields
Notes:
- The aggregated message may become quite large if reporting statistics for many peers, potentially exceeding the MTU and causing fragmentation. Implementations SHOULD provide mechanisms to limit the number of peers included in a single aggregated message or to split large reports appropriately.
- Since counter values are rarely identical across peers, the compression ratio for Statistics Reports is generally lower than for other message types like Peer Down or Peer Up. However, the reduction in protocol overhead remains significant.
- The timing of statistics collection and reporting should be considered. Aggregating near-simultaneous reports from multiple peers maintains temporal coherence while reducing message volume.

Security Considerations All security considerations for BMP apply equally to messages using the Multi-Peer Header mechanism.

IANA Considerations This document requests that IANA assign a following new message type in "BMP Message Types" registry of the BMP parameters namespace (https://www.iana.org/assignments/bmp-parameters/bmp-parameters.xhtml).

Type = TBD (recommended value: 7): Multi-Peer Header

Additionally, this document creates a new registry for "Multi-Peer Message Types" under the BMP parameters namespace. Future additions to this registry require either Standards Action or IESG Approval.