SRTE Overview

SRTE overview

SR-TE is the service that implements a policy architecture for SR networks.

An SR policy is an ordered list of SIDs located at a given headend node in a SR network. That SR policy matches traffic associated with a color number, and steers that traffic to a given endpoint, by appending the SID list in the packets.

On Virtual Service Router, the SR policies can be locally defined, and permit a distributed control across the SR nodes. SR policies can be used by BGP: when incoming BGP routes are received, and are colored, if the (color, nexthop) of each path matches any configured SR policy, then the outgoing traffic associated to the BGP routes will be steered with the corresponding SR policy.

The SIDs used to implement the segment-routing dataplane can be made up of either MPLS labels or IPv6 addresses (SRv6 dataplane). The SR-TE service implements both dataplanes.

The below figure illustrates an SR policy created on the A headend. Traffic flow marked with a defined color will be diverted to the G endpoint, by using the following SID list : <f,g>.

../../../../_images/srte_intro.svg

Diverting traffic from host01 to host02 using SR-TE service

An SR policy is made up of a list of candidate paths indexed by a preference number. Candidate paths forge an SID segment list which may be defined either explicitly or by using the flex algorithm, or dynamically by using a centralised controller. The active candidate path with the biggest preference number will append its segment list to the matching traffic.

Explicit segment list

The following segment types are available when configuring an explicit segment list in the candidate path:

  • Type A: MPLS label for SR. Global labels from the IGP will be chosen.

  • Type B: IPv6 address for SR. Global SID addresses from the IGP locator will be selected.

  • Type F and Type H: IP addresses for link endpoints as local, remote pair. Based on the addresses provuided, and the TE information from the IGP, the local label adjacencies will forge an MPLS segment list.

Flex algorithm candidate paths

Flex algorithm candidate paths rely on the flex algorithm number defined in the IS-IS protocol. Each algorithm stands for an SPF algorithm with constraints, and computes a specific segment list for a given next hop, by using specific Flex algorithm SIDs. Those segment lists are updated in the associated SR candidate path. The following constraints are reused in the dynamic candidate path:

  • using the TE metric instead of the regular metric, as defined in RFC 5305.

  • using the TE minimum delay, as per RFC 8667.

See also

Dynamic candidate paths

Dynamic candidate paths rely on a centralised PCE controller. The candidate path from the SR node use the PCEP protocol to send requests to the PCE to get an answer. The requests include the head-end and the endpoints IP addresses of the locally configured policy, and also a list of constraints and optimisations that the PCE should use to compute, validate a path: metric information or objective functions are added in TLVs.

  • a metric is an optional value used by the PCE to compute paths, like the path-delay or traffic-engineering-cost metrics. By default, the value is considered as an optimisation criterium: the computed value should be as closest as possible as the passed value. The value can also be considered as a constraint, by mandating the PCE to compute a path without exceeding the passed value.

  • an objective-function is an optimization criterium. For instance, the minimize-cumulative-cost function may tell the PCE to minimize the cost when computing a path.

See also

Advantages

SR-TE can be applied to routed traffic, but also MPLS or SRv6 traffic, by associating a unique binding SID to each policy. This value only has a local significance.

In segment routing MPLS dataplane, the binding-sid (BSID) stands for an MPLS label. When entering in the SR domain, the upstream MPLS traffic that uses that label is switched, the BSID is popped, and replaced by the defined segment-list associated to the SR policy. The Virtual Service Router acts as an MPLS gateway: by providing BSID to neighboring devices, the traffic forwarding is delegated to those devices, while the traffic will locally be switched.

In segment routing SRv6 dataplane, the binding-ipv6-sid which stands for an IPv6 address, can be used similarly to MPLS. A seg6local route is added to pop the incoming traffic that uses that IPv6 address, and to encapsulate the traffic with SIDs defined by the explicit IPv6 segment list. The Virtual Service Router acts as an SRv6 gateway.

Also, to reduce the configuration footprint when diverting traffic for a mesh of endpoints with different colors, template policies can be forged. When enabled, incoming BGP colored updates will trigger the creation of policies and candidate paths will be dynamically linked to an IS-IS Flex Algorithm number.

PCEP overview

The SR policies can also be remotely defined, when using a centralized controller that calculates end to end LSPs. The PCEP protocol provides the communication between each SR node acting as a PCC device, and the PCE server. The computed LSPs on the PCE are passed to the PCC for installation on the SR node.

To connect to a remote controller, the PCE server address is configured on the Virtual Service Router. The PCE server can either work in stateless or stateful mode.

In stateless mode, the PCE can compute and validate paths based on PCE requests from the PCC: a dynamic candidate path policy is configured, and contains the constraints that will be used by the PCE to compute the appropriate LSP path.

In stateful mode, the PCC delegates all the SR policy configuration to the PCE. For instance, the PCE keeps the SR policies, and populate the SR policies in the SR node at restart.

See also

  • PCEP configuration.

Standards

Virtual Service Router provides the following features:

RFC 4655:

A Path Computation Element (PCE)-Based Architecture

RFC 5440:

Path Computation Element (PCE) Communication Protocol (PCEP)

RFC 5441:

Encoding of Objective Functions in the Path Computation Element Communication Protocol (PCEP)

RFC 8231:

PCEP Extensions for Stateful PCE

RFC 8281:

PCEP Extensions for PCE-Initiated LSP Setup in a Stateful PCE Model

RFC 8664:

Path Computation Element Communication Protocol (PCEP) Extensions for Segment Routing

rfc:9256:

Segment Routing Policy Architecture

See also

The command reference for details.