]> BGP Flow Specification Extensions for Scheduling Huawei
Beiqing Road Beijing China zhangli344@huawei.com
Huawei
zhoutianran@huawei.com
China Mobile
lizhenqiang@chinamobile.com
Huawei
jie.dong@huawei.com
General IDR Internet-Draft BGP Flow Specification allows conveying flow specifications and associated traffic actions/rules to perform different actions based on traffic characteristics. One use case is steering a specific flow onto a designated path. However, in some scenarios, operators wish to chnge traffic forwarding paths over time. This document extends BGP Flow Specification with scheduling time information to match packets arriving within different time slots. With this extension, the headend can apply different actions to the same traffic at different times.
Introduction and define BGP Flow Specification (FlowSpec), which allows conveying flow specifications and associated traffic actions/rules. BGP FlowSpec rules are encoded within the MP_REACH_NLRI and MP_UNREACH_NLRI attributes . Associated actions are encoded in Extended Community attributes . Existing traffic filter rules and actions in FlowSpec remain effective perpetually; once delivered to the headend, they steer specific traffic onto a fixed path. However, many network scenarios require time-based scheduling of routing paths. In tidal networks such as IP carrier backbone networks, traffic varies periodically. Traffic surges during daily rush hours (typically 20:00–22:00) may lead to congestion on certain links. To mitigate such peak-time congestion, operators wish to divert some traffic onto alternative paths or limit the bandwidth of selected flows, with these policies required to be automatically enabled and disabled at specified times. This document extends BGP Flow Specification with a scheduling time component to match the arrival time of packets. Based on this component, the headend can perform different actions for identical traffic at different times (e.g., diverting traffic to different paths).
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.
FlowSpecv1 Extensions for Scheduling defines 12 components to identify traffic. Building on , this document defines a new component named the scheduling time component to match packet arrival times and trigger corresponding actions. Encoding: <type (1 octet, TBD1), length (1 octet), scheduling time information (variable)+>
  • length: length of the scheduling time information field in bytes.
  • Scheduling time information: time criteria used to filter packets. The format of scheduling time information is specified in .
This new component carries time information that matches the arrival time of IP packets. A packet matches this component if its arrival time falls within the scope defined by the scheduling time information.
FlowSpecv2 Extensions for Scheduling specifies BGP flow specification v2 to address issues encountered during deployment of BGP flow specification v1. In , it defines a list of FSv2 filter family types, including the value 200 assigned for the time filter family type. The format of time filter is shown below:
Format of time filter in FSv2
This document defines a new FSv2 filter component, the scheduling time component, for the FSv2 time filter family. It matches packet arrival times to trigger different actions. The value 100 is recommended as the type value for the scheduling time component. Encoding: <length (1 octet), scheduling time information (variable)+>
  • length: length of the scheduling time information field in bytes.
  • Scheduling time information: time criteria used to filter packets. The format of scheduling time information is specified in .
Format of Scheduling Time Information The format of Scheduling time information is shown as follows:
Schedule of SR Policy
  • Schedule-id: 8-bit value, a unique identifier to distinguish each schedule within a FlowSpec. This value is allocated by the FlowSpec originator.
  • Priority: 8-bit value. This field is used when multiple schedules are simultaneously valid. A higher value indicates higher priority; the default priority value is 10.
  • Flags: 8 bits. Currently only 2 bits are defined; remaining bits are reserved.
    • P (Period format): 1-bit flag indicating the interpretation of the period definition. If P=1, the period is defined by a start time field and an end time field. If P=0, the period is defined by a start time field plus a duration value.
    • S (Schedule type): 1-bit flag indicating the schedule recurrence type. If S=0, the schedule has only one instance; the Frequency and Recurrence Count fields MUST NOT be present in the sub-TLV. If S=1, the schedule has multiple recurring instances; the Frequency and Recurrence Count fields MUST be present.
  • Start Time: 64-bit value, representing the number of seconds since the epoch. It specifies the time when the FlowSpec policy starts to take effect. The epoch is 1 January 1970 at 00:00 UTC.
  • End Time (Duration): 64-bit value. If flag P=1, this field carries the number of seconds since the epoch and specifies when the FlowSpec policy becomes inactive. If flag P=0, this field carries the number of seconds offset from the Start Time and specifies how long the FlowSpec policy remains active.
  • Frequency (optional): 32-bit value. It defines the number of seconds between the start time of one schedule instance and the start time of the next instance. This field indicates the recurrence interval for all instances of this schedule. This field MUST NOT be present if S=0.
  • Recurrence Count (optional): 32-bit value, specifying the total number of repetitions. For example, if set to 2, the schedule repeats twice using the specified Frequency. This field MUST NOT be present if S=0.
Security Considerations BGP Flow Specification inherits the security properties of BGP, including risks of route hijacking, malicious NLRI injection, and tampering of flow rules. The extensions defined in this document add time-based matching criteria to FlowSpec rules and do not introduce fundamentally new security classes of threats. Existing security best practices for BGP FlowSpec and remain fully applicable.
IANA Considerations IANA is requested to allocate a new type value for the Scheduling Time Component in the "Flow Spec Component Types" registry:
Type Description Reference
TBD1 Scheduling Time Component This document
IANA is requested to create a new registry named "Flow Specification v2 Time Component Types". Within this registry, IANA is requested to assign type value 100 for the Scheduling Time Component:
Type Description Reference
0 Reserved This document
1-99 Unassigned This document
100 Scheduling Time Component This document
References Normative References Dissemination of Flow Specification Rules This document defines a Border Gateway Protocol Network Layer Reachability Information (BGP NLRI) encoding format that can be used to distribute (intra-domain and inter-domain) traffic Flow Specifications for IPv4 unicast and IPv4 BGP/MPLS VPN services. This allows the routing system to propagate information regarding more specific components of the traffic aggregate defined by an IP destination prefix. It also specifies BGP Extended Community encoding formats, which can be used to propagate Traffic Filtering Actions along with the Flow Specification NLRI. Those Traffic Filtering Actions encode actions a routing system can take if the packet matches the Flow Specification. This document obsoletes both RFC 5575 and RFC 7674. Dissemination of Flow Specification Rules for IPv6 "Dissemination of Flow Specification Rules" (RFC 8955) provides a Border Gateway Protocol (BGP) extension for the propagation of traffic flow information for the purpose of rate limiting or filtering IPv4 protocol data packets. This document extends RFC 8955 with IPv6 functionality. It also updates RFC 8955 by changing the IANA Flow Spec Component Types registry. Multiprotocol Extensions for BGP-4 This document defines extensions to BGP-4 to enable it to carry routing information for multiple Network Layer protocols (e.g., IPv6, IPX, L3VPN, etc.). The extensions are backward compatible - a router that supports the extensions can interoperate with a router that doesn't support the extensions. [STANDARDS-TRACK] Key words for use in RFCs to Indicate Requirement Levels In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. BGP Flow Specification Version 2 - for Basic IP Huawei Independent Huawei Technologies ATT Verizon HPE BGP flow specification version 1 (FSv1), defined in RFC 8955, RFC 8956, and RFC 9117, describes the distribution of traffic filter policy (traffic filters and actions) distributed via BGP. During the deployment of BGP FSv1 a number of issues were detected, so version 2 of the BGP flow specification (FSv2) protocol addresses these issues. In order to provide a clear demarcation between FSv1 and FSv2, a different NLRI encapsulates FSv2. The IDR WG requires two implementation. Early feedback on implementations of FSv2 indicate that FSv2 has a correct design direction, but that breaking FSv2 into a progression of documents would aid deployment of the draft (basic and adding user ordered actions). This document specifies the basic FSv2 NLRI with user ordering of filters added to FSv1 IP Filters and FSv2 actions. Informative References A Border Gateway Protocol 4 (BGP-4) This document discusses the Border Gateway Protocol (BGP), which is an inter-Autonomous System routing protocol. The primary function of a BGP speaking system is to exchange network reachability information with other BGP systems. This network reachability information includes information on the list of Autonomous Systems (ASes) that reachability information traverses. This information is sufficient for constructing a graph of AS connectivity for this reachability from which routing loops may be pruned, and, at the AS level, some policy decisions may be enforced. BGP-4 provides a set of mechanisms for supporting Classless Inter-Domain Routing (CIDR). These mechanisms include support for advertising a set of destinations as an IP prefix, and eliminating the concept of network "class" within BGP. BGP-4 also introduces mechanisms that allow aggregation of routes, including aggregation of AS paths. This document obsoletes RFC 1771. [STANDARDS-TRACK] BGP Extended Communities Attribute This document describes the "extended community" BGP-4 attribute. This attribute provides a mechanism for labeling information carried in BGP-4. These labels can be used to control the distribution of this information, or for other applications. [STANDARDS-TRACK]