| Internet-Draft | Abbreviated-Title | March 2023 |
| Shen, et al. | Expires 5 September 2023 | [Page] |
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.¶
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 RFC 2119 [RFC2119].¶
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 5 September 2023.¶
Copyright (c) 2023 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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
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. 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¶
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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+¶
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.¶
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].¶
This document requests the creation of a new registry called "Traffic compress Extended Community" under the "Extended Community" registry.¶
SubType Description ------- ------------------------------- TBD Traffic compress Extended Community¶
There are no additional security risks introduced by this design.¶