BGP Flow-Spec Traffic Compress Action

Abstract

Flow-spec is an extension to BGP that allows for the dissemination of traffic flow specification rules and traffic filtering actions. This document specifies a new traffic filtering action to support compressing traffic.¶

1. Introduction

Flow-spec [RFC8955] [RFC8956] is an extension to BGP that allows for the dissemination of traffic flow specification rules and traffic filtering actions. The flow-spec standard defines widely-used filter actions such as discard, rate limit, traffic marking and so on.¶

Data transmitted on the enterprise network, data center, office, and external connections is inconsistent. The data may be text, audio, or video.¶

The BGP flowSpec extension allows traffic filters to be distributed to routers on the entire network. However, some nodes are suitable for compression and have a large compression ratio. Some nodes have no compression space. Some nodes have no compression or decompression capabilities. Therefore, a new traffic action needs to be added to selectively compress different traffic based on the existing traffic filters.¶

For example, database data is transmitted between financial data centers. We need to compress the data of different network nodes to save bandwidth.¶

This document specifies a new traffic filtering action that provides a method of traffic compressing. The details of the action, including compression algorithms, are encoded in newly defined BGP extended communities¶

2. Traffic compress Extended Community

This document proposes a new BGP extended community called the "flow-spec traffic compress action". It has a Generic Transitive Extended Community type "0x80". The sub-type value [to be assigned by IANA] indicates that the global administrator and local administrator fields encode a flow-spec traffic compress action. In the new extended community the 2-byte global administrator field encodes compression algorithms called Compression Parameter Index (CPI) [ RFC-3173]. And the 4-byte local administrator field is reserved for future use.¶

This new BGP extended community 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    0x80    |    Sub-Type   |                CPI               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          RESERVED                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

• Sub-Type: TBD.¶

• CPI: 2 octets. The values 0-63 designate well-known compression algorithms.The values 64-255 are reserved for future use. The values 256-61439 are negotiated between the two nodes in definition of an IPComp Association[RFC3173].¶

• RESERVED: 4 octets. All bits in the local administrator field MUST be set to 0 by the originating BGP speaker and ignored by receiving BGP speakers.¶

Generally, the receive end of Flowspec Traffic Compress Extended Communityfunctions as the compressing end and the transmit end functions as the decompressing end. In addition, the CPI can be delivered through the controller or other devices. In this case, the traffic receiver must have the decompression capability corresponding to the traffic compression extended community.¶

3. Error Handling

If multiple traffic compression extended communities exist in the BGP route attribute, the value of the first traffic compression extended community must be used.¶

The validation of the TLVs/sub-TLVs introduced in this document and defined in their respective sub-sections of Section 2 MUST be performed to determine if they are malformed or invalid. In case of any error detected, the error handling should comply with [RFC7606].¶

7. References