BGP Flow Specification Extensions for Scheduling

Introduction and define BGP Flow Specification (FSv1), 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 . FSv2 is an update of FSv1, it addresses the issues collected during the deployment of FSv1 and provides flexible TLV-based encoding. Existing traffic filter rules and actions in FSv2 remain effective perpetually; once delivered to the headend, the rules and actions are permanent for traffic. However, some operators wish to perform different actions for specific flows at specific time. 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 rate of selected flows, with these policies required to be automatically enabled and disabled at specified times. This document extends BGP FSv2 with a scheduling time component to match the arrival time of packets. Based on this component, the headend can perform different actions for specific 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.

FlowSpecv2 Extensions for Scheduling 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 specific actions. The value 100 is recommended as the type value for the scheduling time component. Encoding: <scheduling time (variable)+> Scheduling time information: time criteria used to filter packets, contains a list of Scheduling Time information. The format of scheduling time information is specified in .

Scheduling Time Information The format of scheduling time information is shown as follows:

Format of Scheduling Time Information

Schedule-id: 8-bit value, a unique identifier to distinguish each schedule within a Filter Component. This value is allocated by the FlowSpec originator.
length: 8 bits, length of the current scheduling time information in bytes.
Flags: 8 bits. Currently only 2 bits are defined; remaining bits are reserved. The reserved bit should be set to 0 and ignored by the receiver.
- 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 start time for traffic matching. The epoch is 1 January 1970 at 00:00 UTC.
End Time (Duration): 64-bit value. If flag P=1, this field specifies the endtime for traffic matching. If flag P=0, this field carries the number of seconds offset from the Start Time and specifies the duration of traffic matching.
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. Value of 0 means repeat infinitely.

Multiple instances of Scheduling Time Information may occur in a scheduling time component TLV. Multiple Scheduling Time Information within the same time component are OR'ed. if any time window matches the packet arrival time, the Time Filter matches.

Procedures

Receiving Procedures When a BGP speaker receives a FSv2 NLRI containing a Scheduling Time Component in the Time Filter Family (type 200):

It validates each scheduling time information in the Scheduling Time Component TLV. Invalid scheduling time information in the component (e.g., inconsistent S flag and optional fields, EndTime ≤ StartTime) SHOULD be silently discarded (other scheduling time information within the same component still valid). If all scheduling time information in the component are invalid, the entire Time Filter is considered not matching.
The speaker installs the FlowSpec rule into the local policy. The rule is persistent in the BGP RIB until receiving a explicit withdrawn.
The forwarding plane evaluates packet arrival time against the scheduling time component.
Other FSv2 filter families in the same NLRI are AND'ed with the Time Filter result.

Matching Procedures A packet matches this FlowSpec rule if and only if:

All non-Time filter families match; AND
At least one valid Scheduling Time Information in the Scheduling time Component matches the packet arrival UTC time.
When the time windows of a scheduling time component expire, the filter will stop matching incoming packets. The expiration will NOT trigger automatic BGP withdrawal until the corresponding explict withdrawal is received.

Operational Considerations All headend nodes executing scheduling FlowSpec rules with a time filter MUST be synchronized to a common UTC time source. Synchronization loss may cause unexpected action execution, even leading to packet loss. The controller originating these FlowSpec NLRI is responsible for converting operator local-time schedules into UTC epoch timestamps. Forwarding nodes only process UTC timestamps and have no awareness of local time zones. A large number of time filters will increase forwarding-plane matching state and CPU overhead for time-window evaluation. Operators SHOULD limit the numbers of time filters on device.

Compatibility According to the description in , BGP speakers that implement FSv2 but do NOT support the Time Filter Family or the Scheduling Time Component will check the syntax, but do not handle the semantic meaning unknown filter component. Existing FSv2 NLRIs without the time filter family are unaffected by this extension.

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 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