BGP FlowSpec Extensions for Large Scale Prefix based Steering

Dynamic traffic steering becomes more and more popular in operator networks. It is desirable that an automatic and scalable mechanism can be provided to dynamically deploy such policies to network devices. BGP FlowSpec provides a flexible mechanism to specify the matching rules and the corresponding actions for specific traffic. Due to the flexibility of BGP FlowSpec, the number of flowspec filtering entries supported in hardware is usually limited, which is suitable for a small number of complicated traffic matching and manipulation policies. In some operator networks, there are requirements of dynamically deploying a large amount of destination prefix based traffic steering policies, thus some scalable mechanism for large scale prefix based traffic steering policy is needed. One possible option is that the controller advertises the destination prefix based steering policy as normal IP routes directly to the network devices. Although this seems straightforward, it is difficult to determine the interaction results of the steering routes and the existing routes in the devices, and may have unexpected impacts to the whole network. Another option is that the controller advertises the destination prefix based steering policy as BGP FlowSpec routes to the network devices. Instead of installing these routes as the BGP FlowSpec filtering entries, the network devices are instructed by the controller to download the prefix based steering policies to their Forwarding Information Base (FIB), so that the number of prefix based steering policy supported is not limited by the number of BGP FlowSpec filtering entries. This document proposes to use the mechanism in the second option, and specifies the required extensions to BGP protocol.

In ISP networks, usually there are multiple paths to a particular destination. The path with better QoS characteristics such as latency, loss, jitter, etc., is preferred. Since these QoS characteristics change from time to time, the decision of path selection also needs to be changed accordingly. Figure 1 shows a typical scenario of prefix based traffic steering in inter-domain ISP networks. As shown in the figure, there are two transit nodes from AS-1 to the destination Prefix-1 in AS-4, saying transit node M in AS-2 and transit node N in AS-3. In normal state, traffic from AS-1 to Prefix-1 goes through transit node M. While transit node N would be preferred when performance degradation happens on transit node M. In that case, traffic should be steered to go through transit node N instead. According to the real time network performance condition, the traffic steering policy needs to be changed dynamically. Thus the operator of AS-1 expects an efficient and convenient mechanism for steering the traffic to different transit nodes.

This section specifies the proposed extension to BGP protocol.

A new Wide Community Atoms TLV "Bit Flags List Atom" is defined. This atom is an array of units of 32 flags numbered from the most significant bit as bit zero. The Length field for this TLV is always a multiple of four bytes, regardless of the number of bits carried, and no padding is required. Unassigned bits are considered as reserved and MUST be set to zero on transmission by the originator of this TLV. Bits not contained in the TLV MUST be assumed to be set to zero.

One flag (bit 31) is defined in this document. When this flag is set to 1, recursive route lookup SHOULD be performed in the local routing table identified by the address family of the received route with this TLV. When this bit is set to 0, recursive route lookup SHOULD be performed in the global routing table.

The assignment of other bits is managed by IANA.

A new Registered Wide BGP Community "Download to FIB" is defined. It is used to instruct the receiving BGP speakers to download the BGP FlowSpec routes carrying this Wide Community into the FIB, instead of installing the FlowSpec routes into FlowSpec filtering entries.

An example of the Download to FIB Wide BGP community generated by the policy controller in Figure 1 is as below:

In order to achieve dynamic prefix based traffic steering in the scenario of Figure 1, the controller of AS-1 constructs a BGP FlowSpec route which carries the following information: Prefix-1 as the Destination Prefix component of BGP FlowSpec NLRI. Traffic-Action Extended Community, with the Route Policy Distribution (RPD) Flag set. This is to indicate that the corresponding FlowSpec filtering rules are used as routing policies. NO_ADVERTISE Community . This indicates that the receiving BGP speaker MUST NOT advertise this BGP FlowSpec route to other BGP peers. "Redirect to IP" Extended Communities , with the global administrator field set to the address of transit node N. "Download to FIB" Wide BGP Community to indicate that the receiving BGP speaker SHOULD download this BGP FlowSpec filtering rule to its FIB. The controller of AS-1 sends this BGP FlowSpec route to the ASBRs of AS-1, i.e. router C and E. On receipt of this BGP FlowSpec route from the controller, the routers processes the received BGP FlowSpec route as follows: Extracts the target prefix Prefix-1 from the Destination Prefix component in the BGP FlowSpec NLRI. Identifies that the RPD Flag in the Traffic-Action Extended Community is set, so the corresponding filtering rules will be used as Routing Policies. Parses the "Download to FIB" Wide BGP Community, and knows that this FlowSpec route SHOULD be downloaded into FIB entry, instead of being installed as FlowSpec filtering entry. And according to the Flag Bit 31 in the Wide Community Parameters TLV, knows that the recursive route lookup should be performed in the global routing table. Extracts the redirect IP address from the "Redirect to IP" Extended Communities, which will be used for the recursive route lookup. After performing the recursive lookup in the designated routing table, the connected next hop is identified and this route is downloaded as a FIB entry into the forwarding plane.

IANA is requested to assign a new code point for the "Bit Flags List Atom" TLV from the "Wide BGP Communities Atom Types" registry. IANA is requested to assign a new code point for the "Download to FIB" Wide BGP Community from the "Registered Wide BGP Communities" registry.

TBD

The following individuals gave significant contributions to this document:

The authors would like to thank Shunwan Zhuang, Nan Wu and Haibo Wang for the valuable discussion on this work.