| Internet-Draft | IGP Flex-Algo with Time Constraint | February 2024 |
| Dong & Zhang | Expires 21 August 2024 | [Page] |
IGP Flexible Algorithm allows IGPs to compute constraint-based paths over the network using different types of metrics or constraints.¶
This document defines a new type of constraint called "Time Constraint", which can be used to control the time period during which a Flex-Algorithm takes effect for constraint-based path calculation. Such mechanism may be useful in network scenarios where either the traffic demand or the characteristics of the network varies as a function of time. The procedures of using Time Constraint in Flexible Algorithm is also described.¶
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 21 August 2024.¶
Copyright (c) 2024 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.¶
IGP Flexible Algorithm [RFC9350] allows IGPs to compute constraint-based paths over the network using different types of metrics or constraints.¶
In some network scenarios, the traffic demand varies as a function of time, and in different time period, the network path for such traffic can be computed using different set of constraints.¶
In some other network scenarios, the characteristics of the network itself, such as the connectivity between nodes, the link attributes or the node attributes may change as a function of time, the network path meeting specific requirements may need to be recalculated at specific time, and the calculation result can be used for a specific time duration.¶
[I-D.ietf-tvr-requirements] specifies that the schedule should be considered for making forwarding decisions and calculating paths in the distributed routing scenario. However, there are no detail descriptions on how to calculate paths in a distributed manner and forward packets based on schedule.¶
This document defines a new type of constraint called "Time Constraint", which can be used to control the time period during which a Flex-Algorithm takes effect for constraint-based path calculation. The procedure of using Time Constraints in Flexible Algorithm is also described.¶
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.¶
The Time Constraints of Flexible Algorithm are used to specify the time when the Flexible Algorithm is in effect, and only the network nodes and links that are operational and meet other constraints of the Flexible Algorithm during the active period can be used for path computation. It also indicates the time at which the constraint-based path computation of this Flexible Algorithm should be performed. Similar to other constraints of Flexible Algorithm, Time Constraint is defined as one sub-TLV of the Flexible Algorithm Definition (FAD). The Time Constraints sub-TLV specifies the flags, initial time, end time, recurrence, slot number and the duration of each time slot when the Flexible Algorithm takes effect (in this document it is called the Flexible Algorithm is active). The encoding of Time Constraint in IS-IS and OSPF are specified in below subsections.¶
IS-IS Flex-Algo Time Constraint Sub-TLV is a sub-TLV of the IS-IS FAD Sub-TLV. It has the following format:¶
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 | Length | Flags | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Initial Time (64 bit) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | End Time (32 bit) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Recurrence (32 bit) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Slot Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Slot #1 Enable Time (32 bit) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Slot #1 Disable Time (32 bit) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ... ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Slot #n Enable Time (32 bit) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Slot #n Disable Time (32 bit) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Sub-TLVs ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type (8 bits): TBD1, used to identify the type of Time Constraint Sub-TLV.¶
Length (8 bits): The size of the value field in octets.¶
Flags (8 bits): All flags are reserved for future use.¶
Reserved (8 bits): Reserved for future use. MUST be set to 0 on transmission and ignored at reception.¶
Initial Time (64 bits): The number of seconds since the epoch. It is the base timeline for the Flex-Algorithm’s time constraint.¶
End Time (32 bits): The number of seconds since the initial time. It indicates the time when the Flex-Algorithm expires. When the end time of a Flex-Algorithm arrives, the routing table of this Flex-Algorithm should be deleted. When the End Time is set to 0, it indicates the Flex-Algorithm never expires.¶
Recurrence (32 bits): This is used to indicate the recurrence period of all the time slots of the Flexible Algorithm in seconds. When the recurrence is set to 0, it indicates the slots in the Flex-Algo are not cyclic.¶
Slot Number (8 bits): It is used to indicate the number of time slot in the following fields. Each time slot consists of enable time and disable time. The time slots indicate the duration when the Flex-Algorithm is considered active.¶
Slot# Enable Time (32 bits): The number of seconds since the initial time. It is used to indicate when the Flex-Algorithm start to take effect for a specific time slot.¶
Slot# Disable Time (32 bits): The number of seconds since the initial time. It is used to indicate when the Flex-Algorithm becomes ineffective.¶
Sub-TLVs: Optional sub-TLVs.¶
OSPF Flex-Algo Time Constraint Sub-TLV is a sub-TLV of the OSPF FAD TLV. It has the following format:¶
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 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Initial Time (64 bit) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | End Time (32 bit) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Recurrence (32 bit) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Slot Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Slot #1 Enable Time (32 bit) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Slot #1 Disable Time (32 bit) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ... ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Slot #n Enable Time (32 bit) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Slot #n Disable Time (32 bit) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Sub-TLVs ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type(16 bits): TBD2, used to identify the type of Time Constraint Sub-TLV.¶
Length (16 bits): The size of the value field in octets.¶
The description, format, and meaning of the flags, Initial Time, End time, Recurrence, Slot Number, Slot# Enable Time, Slot# Disable Time fields remain the same as in the Time Constraint Sub-TLV of IS-IS FAD TLV.¶
The time constraint extension brings some updates to the Flex-Algorithm mechanism. This section describes the updates to Flex-Algorithm Definition advertisement, Flex-Algorithm path calculation, Flex-Algorithm-based packet forwarding and traffic switching between Flex-Algorithms.¶
It should be noted that the process of how a node receive time variable link-state information is out of scope of this document. It is assumed that each node can obtain the time variable information of the whole network by some means.¶
The valid time slots and the recurrence of the Flex-Algorithm can be determined according to the predicted change of the traffic or the network. Multiple time-constrained Flex-Algorithms MAY be defined and advertised for path calculation in different time ranges. In this case there is usually no overlapping between different time-constrained Flex-Algorithms. A time-constrained Flex-Algorithm also includes with other constraints as defined in [RFC9350]. For example, the Metric Type, the Admin Groups, etc. Only a subset of the routers participating in the particular Flex-Algorithm needs to advertise the definition of the time-constrained Flex-Algorithm, in which the time constraints are encoded as one Sub-TLV of the FAD TLV (OSPF) or FAD sub-TLV (IS-IS).¶
When a node is configured to participate in a time-constrained Flex-Algorithm, the node MUST advertise the Flex-Algorithm participation according to the data plane mechanism used with Flex-Algorithm. For SR-MPLS data plane, the mechanisms defined in [RFC8665], [RFC8666], [RFC8667] MUST be used, and for SRv6 data plane, the mechanisms defined in [RFC9352], [RFC9513] MUST be used.¶
Based on the End Time of the Flex-Algorithm, nodes participating in the Flex-Algorithm MAY withdraw the data plane identifiers it advertised for the Flex-Algorithm (e.g. the Algorithm-specific SR SIDs and SRv6 Locators).¶
Constraint-based path computation of a time-constrained Flex-Algorithm SHOULD be performed before the enable time of each valid time slot of the Flex-Algorithm. A local timer MAY be used to determine the time at which the calculation is performed, so that the calculation is finished at the start time of the time slot. The mechanism for calculating Flex-Algorithm paths as defined in section 13 of [RFC9350] still applies here. The path computation SHOULD be based on the network topology at the moment of the start time, possibly with predicted changes of the network topology and attributes which may happen during the time slot. Only network nodes and links that are fully operational during the period of the Flex-Algorithm time slot can used in Flex-Algorithm path computation of that time slot. Topology changes which are received outside any time slot of a Flex-Algorithm are stored only and will not trigger path calculation of the Flex-Algorithm. This way, unnecessary constraint-based path calculation can be avoided.¶
For a time-constrained Flex-Algorithm, the computed paths MUST be installed in the forwarding plane of network nodes which participate in the Flex-Algorithm before the enable time of each time slot of the Flex-Algorithm. For SR-MPLS and SRv6 data plane, the mechanisms of installing Flex-Algorithm-specific forwarding entries as described in section 14 of [RFC9350] applies here.¶
When a packet arrives at the edge of the network, according to the arrival time and local policy, the ingress edge node SHOULD determine which in effect time-constrained Flex-Algorithm will be used for forwarding the packet in the network, then the packet is encapsulated with the Flex-Algorithm-specific SR-MPLS Prefix SID or SRv6 SID corresponding to the selected Flex-Algorithm. The intermediate nodes SHOULD forward the packet according to forwarding entries of the Flex-Algorithm.¶
In order to adapt to the changes in network traffic or network connectivity, multiple time-constrained Flex-Algorithms MAY be provisioned, the effective time slots of which are complementary. This can provide network paths to meet specific requirement at different time period. At the moments when a Flex-Algorithm become inactive (not in any of its valid time slot), traffic SHOULD be switched over to paths calculated with another active time-constrained Flex-Algorithm. Such switchover can be configured via local policy.¶
When a time-constrained Flex-Algorithm become inactive, network edge nodes MUST NOT use Flex-Algorithm-specific data plane encapsulation for any packets received after the disable time of the Flex-Algorithm. While the Flex-Algorithm-specific forwarding entries installed in the forwarding plane SHOULD NOT be deleted, this is to make sure that packets in-flight with Flex-Algorithm-specific data plane encapsulation can be forwarded correctly if the path is still available. Traffic SHOULD be switched to paths of other Flex-Algorithms which can meet the requirement while have complementary time slots.¶
When a Flex-Algorithm expires (the end time of the Flex-Algorithm arrives), the Flex-Algorithm-specific forwarding entries installed in the forwarding plane SHOULD be deleted after a local configured time period, so that the packets in-flight in the network can be forwarded correctly if the path is still available.¶
By the above mechanisms, there is no packet loss during the switchover of time-constrained Flex-Algorithms.¶
This document introduces no additional security vulnerabilities in addition to the ones as described in [RFC9350].¶
IANA is requested to assign a new code point for "Flexible Algorithm Time Constraint Sub-TLV" under the "IS-IS Sub-Sub-TLVs for Flexible Algorithm Definition Sub-TLV" Registry.¶
| Type | Description | Reference |
|---|---|---|
| TBD1 | Flexible Algorithm Time Constraint | This document |
IANA is requested to assign a new code point for "Flexible Algorithm Time Constraint Sub-TLV" under the "OSPF Flexible Algorithm Definition TLV Sub-TLV" Registry.¶
| Type | Description | Reference |
|---|---|---|
| TBD2 | Flexible Algorithm Time Constraint | This document |
The authors would like to thank XXX for the review and discussion of this document.¶