BGP Flow Specification Extensions for Scheduling

Status of This Memo

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 16 April 2027.¶

Copyright Notice

Copyright (c) 2026 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.¶

Table of Contents

1. Introduction

[RFC8955] and [RFC8956] define BGP [RFC4271] 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 [RFC4760]. Associated actions are encoded in Extended Community attributes [RFC4360].¶

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).¶

2. FlowSpecv1 Extensions for Scheduling

[RFC8955] defines 12 components to identify traffic. Building on [RFC8955], 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 Section 4.¶

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

3. FlowSpecv2 Extensions for Scheduling

[I-D.ietf-idr-fsv2-ip-basic] specifies BGP flow specification v2 to address issues encountered during deployment of BGP flow specification v1. In Section 3.1.1 of [I-D.ietf-idr-fsv2-ip-basic], 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:¶

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FSv2 Filter Family type =200  |   Fsv2 filter Family length   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             FSv2 Filter Component TLVs (variable)             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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 Section 4.¶

4. Format of Scheduling Time Information

The format of Scheduling time information is shown 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Schedule-id  |    Priority   |    Reserved   |   Flags   |P|S|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          Start Time                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          Start Time                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      End Time (Duration)                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      End Time (Duration)                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     Frequency (Optional)                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                   Recurrence count(Optional)                  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

• 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.¶

5. 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 [RFC8955] and [I-D.ietf-idr-fsv2-ip-basic] remain fully applicable.¶

6. IANA Considerations

IANA is requested to allocate a new type value for the Scheduling Time Component in the "Flow Spec Component Types" registry:¶

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

7. References

Authors' Addresses