SR-TE Pt. 1 (Overview)

SR-TE replaces RSVP-TE, allowing the operator to program LSPs that take various attributes into account (such as delay, bandwidth, etc) in a Segment Routing network. RSVP-TE used the concept of tunnels, where the operator specified a set of constraints, the router ran CSPF, and determined a hop-by-hop path that was signaled using RSVP. Logically on the router, this path was represented by a tunnel interface, and traffic would be forwarded down this LSP by being forwarded down the tunnel.

With SR-TE, the term “policy” replaces the RSVP-TE term “tunnel.” An SR policy is a stack of segments instead of a hop-by-hop signaled and maintained path as in RSVP-TE. The intent of the policy (i.e. avoid “blue” links, provide 100M bandwidth, etc.) is translated into a list of segments.

PCE

What really sets SR-TE apart is the fact that the computation of the policy path can be done off-box. The router itself can be the computation engine, but a separate device entirely can also be the computation engine. We call this separate device a PCE (path computation engine). Individual routers all consult the PCE for the SR policy SID list.

The PCE is needed when certain constaints are used, such as available bandwidth, or also when calculating paths that traverse multiple IGP domains. In RSVP-TE, bandwidth was reserved hop-by-hop, but this is not possible in SR. Instead, a single, central, PCE can keep track of bandwidth allocations itself. But this means that all SR policies need to be calculated by the PCE, so the PCE can keep track of how much bandwidth is allocated per link within the topology.

Binding SID

This is a new type of SID that represents an SR policy. The instruction that a binding SID represents is to pop the label and forward the traffic down the LSP for the SR policy. To forward traffic down the LSP, the SID list for the policy is pushed onto the packet. So the binding SID represents a pop and push operation.

The binding SID allows other routers in the topology to take a TE path that has a headend of some other router, by simply using a single label to represent that path.

The binding SID can decrease the number of segments imposed at the source. If the source knows that router X has an SR policy that it can use, the source can simply steer traffic to router X, with the bottom label being router X’s binding SID. Router X, upon seeing the binding SID, steers the traffic along the related path calculated by the SR policy.

Using BGP to steer traffic into TE paths

In a service provider network, BGP generally provides the reachability for all services (L3VPN, L2VPN, pseudowires, etc.). SR-TE allows a BGP route to be advertised with a color. This color is an extended community. The color defines a TE SLA intent, such as min delay, avoid "blue" links, etc.

All routers will have basic templates that define these colors. If a router receives a BGP route with a color that matches a pre-defined template, the router will send traffic matching that BGP route along the SR-TE path for that policy. The process of steering traffic based on the BGP route is called automated steering. The process of dynamically creating an SR policy based on the color template and the BGP next-hop as the policy tailend is called on-demand next-hop (ODN).

SR-TE Database

SR has a TE database just like the classic TED. SR-TE collects topology information from the IGP as well as BGP-LS. This allows the SR-TE database to contain multi-domain information. Routers in the IGP export their LSDB using BGP-LS, and the PCE can “download” all IGP LSDBs using BGP-LS.

The IGP LSDB needs to be exported into SR-TE using the command distribute link-state. This exports the LSDB into the SR-TE DB. It also makes the LSDB available to BGP-LS. Data from BGP-LS received on a router is automatically injected into the SR-TE DB locally.