| Internet-Draft | PCE SR Policy Scheduling | March 2025 |
| Zhang, et al. | Expires 4 September 2025 | [Page] |
Segment Routing (SR) policy enables instantiation of an ordered list of segments with a specific intent for traffic steering. When using SR policy in a time-variant network, delivering the time-variant information associated with paths is necessary in some scenarios.¶
This document proposes extensions to PCE SR Policy to deliver the schedule information of candidate path (segment list) and its associated attributes.¶
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 4 September 2025.¶
Copyright (c) 2025 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.¶
[RFC9657] introduces a set of time-variant network use cases where the topology of the network changes predictably. When the networks uses traditional routing protocols, it takes these topology changes as unexpected events and may cause and packet loss. However, the topology changes of these networks can be predicted in advance, therefore some measures can be taken in advance to prevent the packet loss. With this idea, [I-D.ietf-tvr-requirements] describes the requirements of using the time-variant information in a network. In Section 3.4.1 of [I-D.ietf-tvr-requirements], it describes the centralized routing scenarios with time-variant information, in which the network entities receive the time variable information and traffic forwarding rules directly from a logically centralized source(an Orchestrator or network controller). The time-variant information is especially essential when there is a risk that a logically centralized source may loses connectivity with the network entities.¶
[RFC8664]specifies extensions to the Path Computation Element Communication Protocol (PCEP) that allow a stateful PCE to compute and initiate Traffic-Engineering (TE) paths, as well as a Path Computation Client (PCC) to request a path subject to certain constraints and optimization criteria in SR networks. [I-D.ietf-pce-segment-routing-policy-cp] extends [RFC8664] to support signaling SR Policy Candidate Paths as PCEP LSPs and to signal candidate paths of the SR Policy. It signals SR Policy Candidate Paths as PCEP LSPs and signal Candidate Path membership in an SR Policy by means of the Association mechanism. The segment lists of each candidate path and their associated attributes are signaled by the Path Attribute Object defined in [I-D.ietf-pce-multipath]. However, when using SR Policy in a time-variant network, it can't advertise the schedule information associated with paths.¶
This document proposes extensions to PCE SR Policy to carry the schedule information of candidate paths/segment lists.¶
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.¶
Most of the time-variant network use cases using PCE SR Policy could benefit from this work. In some cases, carrying the time-variant information with SR Policy is essential.¶
This section describes the cases that requires extending SR Policy with schedule information.¶
In some time-variant network cases, the links between the network entities and network controller may very weak or intermittent, this is very typical in Resource Preservation and Dynamic Reachability network[RFC9657]. In these cases, Real-time SR policy advertising (before changes occur) may not be timely. For example, when a link of an old path is about to be disconnected, the network controller is going to advertise a new path to the headend. However, the link between the headend and the network controller is not available. As a result, the new path cannot be advertised in time, causing packet loss.¶
Therefore, in these cases, once the links between the headend and network controller are available, the controller need to advertise the paths with schedule information for a period in the future to the headend. Then the headend could determine valid paths in the future based on the schedule information of SR policy.¶
There are also some time-variant network cases that topology changes frequently. This is very typical when the number of network entities is very large (For example, a Dynamic Reachability network with hundreds or thousands of nodes). In this kind of time-variant network, a path form one network entity to another changes frequently, sometimes it can only be maintained for a few minutes or seconds.¶
Considering that there are multiple paths in a network that computed by the controller, the SR Policies with candidate paths may be advertised to the headend every few seconds. It poses great changeling to the network controller. However, using schedule information could advertise several paths at a time, which greatly mitigate the pressure of network controllers.¶
[RFC8934] defines the SCHED-LSP-ATTRIBUTE and SCHED-PD-LSP-ATTRIBUTE TLV to indicate the LSP is a non-periodical scheduling LSP or a periodical scheduling LSP. However, it can't express a LSP with complex schedules. On the one hand, the format of these TLVs are very simple, each TLV can only descripts one duration or a periodical duration, on the other hand, it requires that only one SCHED-LSP-ATTRIBUTE TLV SHOULD be present in the LSP object, which means each scheduling LSP can only have one duration or periodical duration.¶
Therefore, the extensions of [RFC8934] could be applicable in some cases with simple schedules, but it is not flexible enough to be applied in the cases with complex schedules(such as the cases listed in Section 2). A more general format of Schedule Information TLV is defined in this draft to cover different kind of cases.¶
The schedule information TLV indicates one or more valid durations. The format of Schedule Information TLV 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | / Schedules / | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: TBD1¶
Length: the size of the value field in octets.¶
Schedules: one or more schedules, each schedule indicates the duration when the candidate path (segment list) is active. The format of each schedule 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags |S|P|R| Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Start Time | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Start Time(Continue) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | End Time/Duration | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | End Time/Duration(Continue) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Recurrence count/Bound(Optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Recurrence count/Bound(Optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Frequency (Optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Schedule-id: 32-bit value, the unique identifier to distinguish each schedule within a SR Policy, this value is allocated by the SR Policy generator.¶
Flags: 8 bits, currently only 3 bits are used, the other bits are reserved.¶
Length: 8 bits, indicates the length of this schedule in octets.¶
S (Schedule type): one-bit flag to indicate the type of a schedule. If S=0, it indicates the schedule only has one instance, the Recurrence Count/Bound, Frequency and Interval field should not be included in the sub-TLV; If S=1, it indicates the schedule has multiple instances, the Recurrence Count/Bound, Frequency and Interval field should be included.¶
P (Period type): one-bit flag to indicate the description type of a period. if P=1, then the period is described by a start time filed and an end time field; If P =0, then the period is described by a start time field and a duration time field.¶
R (Recurrence bound type): one-bit flag to indicate the how to determine whether the recurrence is end. if R=1, then the end of recurrence is determined by a detail timepoint; If R = 0, then the end of the recurrence is determined by the number of occurrences.¶
Start Time: 64-bit value, the number of seconds since the epoch, it indicates when the candidate path (segment list) and its associated attributes start to take effect.¶
End Time/Duration: 64-bit value, if the flag P=1, then it is the number of seconds since the epoch, it indicates when the candidate path (segment list) and its associated attributes becomes ineffective. If the flag P=0, then it is the number of seconds since the Start Time, it indicates how long the candidate path (segment list) and its associated attributes are effective.¶
Recurrence Count/Bound(optional): 64-bit value, this field SHOULD be included when the flag P is set to 1. When the flag R=0, then this field indicates the max number of occurrences. For example, if it is set to 2, then the schedule will repeat twice with the specified Frequency and Interval. When the flag R=1, then tis field indicates the bounded timepoint of recurrence, it is descripted by the number of seconds since the epoch.¶
Frequency(optional): 32-bit value, this field should be included when the flag S is set to 1. It is the numbers of seconds since the Start Time of an instance to the Start Time of next instance. This field indicates the recurrence frequency for all the instance of this schedule.¶
As described in [I-D.ietf-pce-segment-routing-policy-cp], SR Policy is represented by a new type of PCEP Association, called the SR Policy Association. The SR Candidate Paths of an SR Policy are represented by the PCEP LSPs within the same SRPA.¶
When applying schedules to a Candidate Path of an SR Policy, the LSP Object[RFC8231] is required to be extended to support the Schedule Information TLV. The Schedule Information TLV could be an optional TLV present in the LSP Object.¶
When there are multiple segment lists within an SR Policy Candidate Paht, [I-D.ietf-pce-multipath] defines the Path Attribute object(PATH-ATTRIB) to carry per-path information. When applying schedules to a Segment List, the PATH-ATTRIB object is required to be extended to support the Schedule Information TLV. The Schedule Information TLV could be an optional TLV present in the LSP Object.¶
TBD¶
IANA maintains a sub-registry "PCEP TLV Type Indicators" in the "Path Computation Element Protocol (PCEP) Numbers" registry. IANA is requested to make the following allocations from this sub-registry.¶
| Value | Description | Reference |
|---|---|---|
| TBD1 | Schedule Information (SI) TLV | This document |