BMP Compression
draft-msri-grow-bmp-compression-00

Abstract

This document provides specification for an optional compressed BMP Feed from a router to BMP station.

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 RFC 2119 RFC 8174 when, and only when, they appear in all capitals, as shown here.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on April 17, 2020.

Copyright Notice

Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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.

Table of Contents

• 1. Introduction
• 2. Procedures
• 2.1. Starting Compressor Capability
• 2.2. Compression Information TLV
• 2.3. Compressed BMP Messages
• 2.4. Compressor Overflow
• 2.5. Error Handling
• 2.6. Processing of Compressed Route Monitoring messages
• 3. Acknowledgements
• 4. IANA Considerations
• 4.1. BMP Compression Information TLV
• 4.2. BMP Compression Route Monitoring message type
• 5. Security Considerations
• 6. Normative References
• Authors' Addresses

1. Introduction

The BGP Monitoring Protocol (BMP) allows monitoring of Rib-in RFC7854, Loc-Rib,BGP local-rib and Rib-in and Rib-Out monitoring allows pre-policy and post-policy view of the prefix. Thus, for a scaled setup, with all these kinds of monitoring enabled, BMP will get a lot of back pressure in the protocol as it needs to dump a huge data for its monitored peers, through a single socket towards BMP station. BGP update PDU which is part of the BMP Route-monitoring (RM) message is also increasing. It is no more limited to 4K as noted in draft-ietf-idr-bgp-extended-messages-21. Essentially, BMP is heading towards becoming I/O bound monitoring protocol. This document proposes compression of BMP feed towards BMP station. Compression will ease the pressure on TCP socket between a router and BMP station. Such a scheme would be useful if a route can spare some extra CPU for BMP operation.

As it must be obvious, this scheme will require compressor mechanism at the BMP speaking router and a decompressor on the BMP station. The compression mechanism used at the BMP speaking is an implementation specific detail and is beyond the scope of this specification.

2. Procedures

2.1. Starting Compressor Capability

BMP compression feature on the router and BMP decompressor feature on the BMP station has to be present at the same time. Enabling compression feature at router end only will lead to incomprehensible data at the BMP station end. Also same technique should be used to compress and decompress the data on wire. Using different technique to compress and decompress would lead to incomprehensible data at the BMP station end.

BMP compression feature on the router and BMP decompressor feature on the BMP station can be enabled via configuraton. Once this feature is enabled between router and BMP station, the monitored router should indicate this to the BMP Station using new Compression Information TLV as described in following section.

From that point onwards, the router would send the compressed BMP feed towards BMP station. BMP session needs to be bounced every-time this feature is enabled on a current active BMP session.

2.2. Compression Information TLV

As noted in RFC7854, the initiation message provides a means for the monitored router to inform the monitoring station of its vendor specific details. It can carry Information TLVs containing information about the monitored router.

The monitored router MUST communicate the compression capability to BMP staton using Compression Information TLV described below.

 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 (2 octets)   |     Length (2 octets)         |
+-------------------------------+-------------------------------+
| CM | CMINFO |                Reserved                         |                
+---------------------------------------------------------------+


                  Figure 1: Compression Information TLV

• Type = TDB1 (2 Octets): Compression Information TLV type.
• Length (2 Octets): indicates the length of the value field of the Compression Information TLV. The value field further consists of the Compression string.
• CM (4 bits): CM indicating DEFLATE compressed format value as specified in RFC1950.
• CINFO (4 bits): INFO as specified in RFC1950. Invalid values MUST lead to the capability being ignored. The compressing peer MUST use this value for the parametrization of its algorithm.

2.3. Compressed BMP Messages

Following rules should be following for achieving BMP feed compression:

1. A new message type, Compressed Route Monitoring (CRM), MUST be used. This is to ensure backward compatibility with BMP stations that do not support the compression capability. The message type is same in structure as described by TLV support for BMP Route Monitoring and Peer Down Messages. Compression is to be applied only to this message type, all other BMP message types shall not be compressed.
2. Compression is applicable to all the payload following the Common Header, described in Section 4.1 of. This allows to read the total BMP message length, i.e. to perform sanity checks against socket and compressor information.
3. Each compressed BMP message MUST be sent as a block, i.e. the decompression MUST be able to yield decompressed results of the without waiting for further compressed updates. This is different from the normally used stream compression mode.
4. The compressed message MAY exceed the maximum message size but in such case compressor overflow per Section 2.4 MUST be invoked.

2.4. Compressor Overflow

This should be handled in same was as described in draft-przygienda-idr-compressed-updates.

2.5. Error Handling

If the decompression on the BMP station fails for any reason, it needs to bring down the BMP session.

If the compression on the monitoring router fails for any reason, it is at the discretion of the router to handle it. It may try it few more times. In the worse case it MAY bring down the BMP session

2.6. Processing of Compressed Route Monitoring messages

A BMP station receiving a compressed message SHOULD process it as follows:

1. Decode the BMP Common Header where message length is specified
2. Decompress remainder of the Compressed Route Monitoring message and determine the decompressed message size from the decompressor
3. Decode the BMP Per-peer header
4. Decode the BGP UPDATE PDU header to infer the presence of trailing TLVs
5. Decode the BMP message TLVs
6. Decode the actual BGP UPDATE PDU

3. Acknowledgements

TBD.

4. IANA Considerations

This document requests that IANA assign the following new parameters to the BMP parameters name space.

4.1. BMP Compression Information TLV

This document defines the BMP Compression Information TLV Header with Type = TBD (Section 2.2).

4.2. BMP Compression Route Monitoring message type

This document also defines the BMP Compressed Route Monitoring message type with Type = TBD (Section 2.3).

5. Security Considerations

It is not believed that this document adds any additional security considerations.

6. Normative References

Authors' Addresses