BGP Flow Specification Extensions for Path Scheduling
Internet-Draft draft-zzd-idr-flowspec-path-scheduling-02
Li Zhang, Ed.
Huawei
Beiqing Road
Beijing
China
zhangli344@huawei.com
Tianran Zhou
Huawei
zhoutianran@huawei.com
Jie Dong
Huawei
jie.dong@huawei.com
29 June 2024
General
IDR
Internet-Draft
Path scheduling is required in many network scenarios. For example, some links or nodes will be shut down in the tidal network when the traffic decreases, which may lead to the expiration of some routing paths.
This document defines a new type of component for BGP Flow Specification to identify the packets arrived at different time slot. Based on that, the headend can steer packets into different paths at different time.
Introduction
[RFC8955] and [RFC8956] define the BGP [RFC4271] Flow Specification (FlowSpec) that allows conveying flow specifications and traffic Action/Rules associated. BGP Flow specifications are encoded within the MP_REACH_NLRI and MP_UNREACH_NLRI attributes [RFC4760]. Rules (Actions associated) are encoded in Extended Community attribute [RFC4360].
The existing traffic filter rules and actions in FlowSpec are always effective and will steer specific traffic into one path once been delivered to the headend. However, there are many scenarios that need to schedule routing paths in the network.
[I-D.ietf-tvr-use-cases] introduces a set of use cases where the topology of the network changes predictably. The topology change may cause some of the paths invalid, and lead to path reselection or even recalculation. However, the reselection or recalculation takes a period of time, which will affect packet forwarding and cause problems such as packet disorder and packet loss. However, on a network with predictable topology changes, the ingress node knows future topology changes, it can schedule the forwarding paths in advance, and steer flows to different set of paths based on time to prevent packet forwarding from being affected by topology changes.
This document defines a new type of component for BGP Flow Specification to identify the packets arrived at different time slot. Based on that, the headend can steer packets into different paths at different time.
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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
Motivation
[I-D.ietf-tvr-use-cases] introduces the time variant network use cases, the tidal network is one of the typical time variant network scenarios. In the tidal network, the traffic volume varies greatly at different time. In order to reduce the power consumption, some of the links and nodes may be shut down when the traffic is at a low level.
In this scenario, the controller can generate a FlowSpec with shceduling time rule to identify the packets arrivaling time and corresponding paths. The headend doesn’t need to wait for the advertisement of topology change and just steer traffic in to different pathes based on the flowSpec with scheduling time information, the affection of topology change is minimized.
Scheduling time information in FlowSpec
[RFC8955] defines 12 Components to identify different traffics. Based on [RFC8955], this document defines a new Component to identify the arrival time of packets, so as to enable path scheduling.
Encoding: <type (1 octet), length (1 octet), scheduling time information (variabile)]+>
Defines the time information that matches the arrival time of packets. This component matches if either the arrival time of an IP packet in the scope of scheduling time information.
The Scheduling time information has two formats according to the change regularity of network topology. They are Aperiodic Scheduling Time Information (ASTI) and Periodic Scheduling Time Information (PSTI).
Aperiodic Scheduling Time Information
The ASTI indicates one or more group of matching time slot (each includes the enable time and disable time) for the packets. The format of ASTI is shown as follows:
Format of ASTI

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          Enable Time                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         Disable Time                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
/                          Variable                             /
|                                                               |

Type: used to identify the type of scheduling time information. The value and corresponding types are shown as follows:
Value | Type
0x01 | Aperiodic Scheduling Time Information
0x02 | Periodic Scheduling Time Information
Enable Time: the time in seconds indicates the start time when the packets matching.
Disable Time: the time in seconds indicates the end time when the packets matching.
Variable: one or more groups of time information (A information group is composed of Enable Time and Disable time) may be included in one ASTI.
Periodic Scheduling Time Information
The PSTI indicates one or more group of periodic matching time slot (each includes period, enable time and disable time) for the packets. The format of PSTI is shown as follows:
Format of PSTI

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                            Period                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          Enable Time                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         Disable Time                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
/                          Variable                             /
|                                                               |

Type: as defined in clause “Aperiodic Scheduling Time Information”
Length: the size of the value field in octets.
Period: the time in seconds between the enable time of one repetition and the enable time of the next repetition.
Enable Time: the time in seconds indicates when the path(s) is(are) enabled.
Disable Time: the time in seconds indicates when the path(s) is(are) disabled
Variable: one or more groups of time information(A information group is composed of Period, Enable Time and Disable time) may be included in one PSTI.
Procedures
When the headend device (as a FlowSpec client) receives a instruction with scheduling time information from a BGP FlowSpec Controller, it will steer the traffic packets matching the time slot and other conditions in the Flowspec instruction into a specific path.
Security Considerations
These extensions to BGP FlowSpec do not add any new security issues to the existing protocol.
IANA Considerations
This document defines a new Component in the registry " Flow Spec Component Types" to be assigned by IANA:
Value | Description | Reference
TBD1 | Scheduling Time Information | This document
References
Normative References
[RFC8955]

Dissemination of Flow Specification Rules
C. Loibl
S. Hares
R. Raszuk
D. McPherson
M. Bacher
December 2020
RFC 8955
DOI 10.17487/RFC8955
[RFC8956]

Dissemination of Flow Specification Rules for IPv6
C. Loibl, Ed.
R. Raszuk, Ed.
S. Hares, Ed.
December 2020
RFC 8956
DOI 10.17487/RFC8956
[RFC4760]

Multiprotocol Extensions for BGP-4
T. Bates
R. Chandra
D. Katz
Y. Rekhter
January 2007
RFC 4760
DOI 10.17487/RFC4760
[RFC2119]

Key words for use in RFCs to Indicate Requirement Levels
S. Bradner
March 1997
BCP 14
RFC 2119
DOI 10.17487/RFC2119
[RFC8174]

Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words
B. Leiba
May 2017
BCP 14
RFC 8174
DOI 10.17487/RFC8174
Informative References
[RFC4271]

A Border Gateway Protocol 4 (BGP-4)
Y. Rekhter, Ed.
T. Li, Ed.
S. Hares, Ed.
January 2006
RFC 4271
DOI 10.17487/RFC4271
[RFC4360]

BGP Extended Communities Attribute
S. Sangli
D. Tappan
Y. Rekhter
February 2006
RFC 4360
DOI 10.17487/RFC4360
[I-D.ietf-tvr-use-cases]

TVR (Time-Variant Routing) Use Cases
Edward J. Birrane
JHU/APL
Nicolas Kuhn
Thales Alenia Space
Yingzhen Qu
Futurewei Technologies
Rick Taylor
Ori Industries
Li Zhang
Huawei
29 February 2024
Internet-Draft draft-ietf-tvr-use-cases-09