Schedule for Segment Routing Policy

Introduction Segment Routing (SR) policy is a set of candidate SR paths consisting of one or more segment lists and necessary path attributes. It enables instantiation of an ordered list of segments with a specific intent for traffic steering. specifies how BGP may be used to distribute SR Policy candidate paths. It introduces a BGP SAFI with new NLRI to advertise a candidate path of a Segment Routing (SR) Policy. introduces a set of use cases where the topology or attributes of the network changes predictably. The topology changes may influence tha validity of some paths, and lead to path reselection or even recalculation. However, the reselection or recalculation takes a period of time, which will influence packet forwarding and cause problems such as packet disorder and packet loss. However, on a network with predictable topology changes, the headend 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 influenced by topology changes. In the scenario of SR-policy-based TE paths, the resource allocation efficiency is a big challenge. Some flows just last for a short time, but the TE paths resources for the flows are usually reserved for a long time and cannot be used by other services. Therefore, the SR policy originator can generate a policy with time-limited paths and resources, the headend schedules these paths over time to improve the utilization of resources. This document extends SR Policy to include the schedule time of candidate paths/SR lists and applies to both SRv6 and SR-MPLS.

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.

SR-Schedule Definition for SR Policy The Segment Routing policy architecture is specified in . An SR Policy is associated with one or more candidate paths. A candidate path is either dynamic, explicit, or composite. The related concepts with the SR-Schedule definition in this document are listed as follows. An explicit/dynamic candidate path is expressed as a Segment-List or a set of Segment-Lists directly or by computation. If a candidate path is associated with a set of Segment-Lists, each Segment-List is associated with weight for weighted load balancing. The default weight is 1. A composite candidate path is defined in .

SR-Schedule of a Segment List A segment list represents a specific source-routed path to send traffic from the headend to the endpoint of the corresponding SR policy . The SR-Schedule of a segment list is defined as the valid period of the path between a source node and a destination node.

SR-Schedule of a Candidate Path In the case of an explicit/dynamic candidate path, if it is expressed as a single Segment-List, then the SR-Schedule of the candidate path is the same as that of the SR-Schedule of the segment list as described in . In the case of an explicit/dynamic candidate path, if it is expressed as a set of Segment-Lists (for load-balancing), then the SR-Schedule of the candidate path is defined as the valid period of all the Segment-Lists in the set.

The Framework of SR-Schedule for SR Policy

Framework of SR-Schedule for SR Policy

Schedule Information Acquisition The SR-Schedule of a segment list is defined as the valid period of the path, see . The valid period of a path can be limited by a variety of factors, for example the flow’s predicted variation, the predicted availability of nodes and links. The schedule information could be acquired from the Network Manager or network devices by YANG data model or routing protocol advertisement.

SR-Schedule Computation The schedule information is sent to the network controller or the headend where the SR-Schedule is computed. Depending upon the source of time constraint, the computation methods are different, which are described in the following subsections.

SR-Schedule Computation with Flow Constraint When the flow with predictable time limit requests a SR path and the topology is stable, the SR-Schedule calculation only needs to consider the time limit of the flow. During calculation, the controller needs to calculate the optimal path that meets flow requirements, and then generate the SR-Schedule based on the flow variation regularity.

SR-Schedule Computation with Topology Constraint When the flow is constant but the network topology changes predictably, the SR-Schedule calculation only needs to consider the topology change. During calculation, multiple paths need to be calculated based on flow requirements. The valid time of each path is the intersection of the available time of all nodes and links in the path. There must be no gap between two paths adjacent in time to ensure the transmission will not be interrupted.

SR-Schedule Computation with Mixed Constraint When the requested flow has a predicable time limit and the topology also changes predictably, the SR-Schedule calculation needs to consider both the flow and topology time constraints. During calculation, the controller first obtains the period that needs to be covered according to the flow time constraint. Then, the controller calculates multiple paths that meet the flow's requirements. The valid time of each path is the intersection of the available time of all nodes and links in the path. There must be no gap between two paths adjacent in time to ensure the transmission will not be interrupted.

SR-Schedule Enforcement SR Policy as per does not include SR-Schedule in the SR Policy encoding structure. As specified in , the SR-Schedule is encoded in the SR policy structure as shown in and . After the SR-Schedule computation, the SR-Schedule is enforced along with the SR Policy to the headend of the corresponding path.

SR Policy Structure with SR-Schedule at Candidate Path Level Attributes: Tunnel Encapsulation Attribute (23) Tunnel Type: SR Policy (15) Binding SID SRv6 Binding SID Preference Priority Policy Name Policy Candidate Path Name Explicit NULL Label Policy -----> Scheduling Time Information (SR-Schedule) Segment List Weight Segment Segment ... ... ]]>

SR Policy Structure with SR-Schedule at Segment List Level Attributes: Tunnel Encapsulation Attribute (23) Tunnel Type: SR Policy (15) Binding SID SRv6 Binding SID Preference Priority Policy Name Policy Candidate Path Name Explicit NULL Label Policy Segment List --------> Scheduling Time Information (SR-Schedule) Weight Segment Segment ... ... ]]>

Handling Behaviors on the Headend After the SR Policy with SR-Schedule is computed, the headend performs the handling behaviors. After obtaining the SR Policy with SR-Schedule, the headend needs to select the available paths at this moment according to the effective time of the candidate path and the segment list. When a packet arrives, the headend encapsulates the segment list of the forwarding path in the packet header based on the available paths. If no path is available at a certain time point, the SR Policy is considered malformed and should be logged with error.

Security Considerations specifies in detail the SR Policy construct (introduced in ) and its security considerations. The additional SR-Schedule attribute information can be sensitive in some deployments and could influence SR path setup, selection and switching with adverse effect. The protocol extensions that include SR-Schedule need to take this into consideration. This document does not define any new protocol extensions and thus does not introduce any further security considerations.

IANA Considerations

Acknowledgement