SR-TE · PCEP · BGP-LS · EPE

An SR-TE controller for open routers.

A router chooses the best path from where it stands, and for almost everything you carry that is the right answer. Three decisions need a view of the whole network instead: reserving capacity along a path, keeping two services off the same links, and choosing which peering a service leaves by. Traffic Dictator, from Vegvísir Systems, computes those against the live topology and installs the paths on IP Infusion’s open routers running OcNOS.

See it work Get the application note
2open protocols, both directions
2ways to deliver a policy
10capabilities exercised in the joint lab
What traffic engineering is for

What your routers already do, and what a controller adds.

OcNOS routers already do a great deal on their own, with ECMP, TI-LFA local protection and Flex-Algo planes built inside the IGP. A controller adds only the decisions that need a view of the whole network. The tag on each card says which half delivers it.

Stop one failure from causing the next

TI-LFA precomputes a local repair path, so the router switches onto it without waiting for the network to reconverge. The controller spreads that reroute across links with spare capacity, so the first failure does not cause a second.

OcNOS + controller

Put latency-sensitive traffic on a short path

Flex-Algo builds a low-delay plane inside the IGP. Trading, media and mobile fronthaul follow it, while everything else keeps taking the cheapest route.

OcNOS on its own

Reserve capacity for a service you sold

The policy carries a bandwidth figure. The controller checks for free capacity before it installs the path, and holds the policy back if a link is already full.

OcNOS + controller

Use the links you are already paying for

ECMP already fills your equal-cost links. The controller places services on the unequal-cost ones, turning idle capacity into capacity you can sell.

OcNOS + controller

Keep the backup off the links the primary uses

A disjoint group makes separation part of the policy, so a protecting path never shares a link with the one it protects.

OcNOS + controller
How it works, end to end

How a constraint you type becomes a label the router pushes.

In this design only two protocols cross between the two halves, and because both are standard, either half can be replaced on its own.

Two words the rest of this page uses

A segment list is an ordered set of labels. Each label names a router or a peering, and the head-end router pushes them onto the packet so that it visits them in order. A policy is a head-end, an endpoint, and the constraints that shape the list between them.

Segment routing traffic engineering control plane: four OcNOS routers form an IS-IS segment routing domain, one of them exports the link-state topology to the Vegvísir Traffic Dictator controller over BGP-LS, and the controller installs the computed SR-TE policy back to the head-end router over PCEP, while an external autonomous system peers at the border and is represented by a BGP Peer SID.
How the two halves meet: OcNOS runs IS-IS with segment routing and publishes the topology over BGP-LS, Traffic Dictator computes the path under your constraints and installs it back over PCEP.
IP Infusion OcNOS Data plane and control plane

It ships as a complete router, because IP Infusion integrates, validates and supports the hardware and OcNOS together, so responsibility for the hardware and the software together sits with one vendor.

  • Runs the network. IS-IS with segment routing extensions, so labels, ECMP and TI-LFA fast reroute all run in the routers themselves.
  • Acts as the head-end. Installs the policy it is given, pushes the segment list, and reports the operational state back.
  • Labels the exits. Allocates a BGP Peer SID for each external peering, so the controller can name that peering in a segment list.
Vegvísir Systems Traffic Dictator Control plane only

It ships as a Docker container, on a server, in an existing virtualization environment, or on a router able to host containers, with an HTTP API for automation.

  • Builds the graph. Node, Link and Prefix information arrives over BGP-LS and becomes a live topology with the segment IDs attached.
  • Holds the constraints. Explicit hops, link affinities, bandwidth, disjoint groups and egress peers are all expressed as constraints on a policy.
  • Computes and installs. Works out the segment list, pushes it to the head-end, then updates it when the topology moves.
Where the bandwidth ledger lives

OcNOS can perform distributed traffic steering using IGP mechanisms such as Flex-Algo, while an external PCE or controller can compute explicit SR policies using network-wide constraints. Bandwidth is the constraint that needs a single view: segment routing gets its scale by not signalling reservations hop by hop, so the running total of what every policy has claimed is held centrally instead. You set that figure per policy, and it does not resize itself from measured traffic today. RSVP-TE takes the other approach and signals a reservation at every hop.

The sequence, start to finish

Four steps take you from switching segment routing on to a policy running in the network.

The first two are one-off setup on the routers. The last two are what you repeat for every policy you create.

01

Turn on segment routing

IS-IS carries the segment routing extensions on every router, together with the traffic engineering extensions, so link bandwidth and admin groups are advertised as well. The labels come from segment routing itself.

02

Export the topology to the controller

One router redistributes the link-state database into BGP-LS with distribute bgp-ls and peers with the controller.

03

Define the policy and its constraints

A policy names a head-end, an endpoint and the constraints it has to meet. The controller computes the path against the live topology and returns a segment list, which is the list of labels the head-end will push onto the packet.

04

Install it, then keep it current

The controller sends the policy over PCEP, and the head-end reports back that it is up and forwarding on it. If the topology changes later, the same policy is updated in place rather than rebuilt.

Constraint by constraint

How each constraint changes the path the controller returns.

Select a constraint below to see the path and the labels it produces. Every segment list and metric shown here is output recorded in the joint lab.

Swipe the diagram sideways to follow the path

Interactive constraint picker on a simplified view of the validated lab topology Four routers R1 to R4 and an external autonomous system. R3 is the head-end on the left. Two link groups are tagged: a BLUE group covering R3 to R1, R1 to R2 and R3 to R4, and a YELLOW group covering R3 to R2 and R2 to R4. R2 peers with AS 101 on the right. Choosing a constraint highlights the path the controller computes and shows the resulting segment list, which is also given in text beside the diagram. admin-group BLUE admin-group YELLOW eBGP peering 40 Gbps held 40 Gbps held R3 head-end R1 16001 R2 16002 R4 16004 AS 101 25600 destination destination
What the controller computed

What OcNOS installs
Path
Segment list
Aggregate metric

Five constraints and the path each one returns

Stay on the blue links, a link affinity constraint
Path R3 to R4. Segment list 16004. Aggregate metric 10, one hop. Every link on the path must carry the BLUE tag, and the direct R3 to R4 link does, so one node segment is enough. Policy R3_R4_BLUE, affinity-set BLUE_ONLY.
Stay on the yellow links, a link affinity constraint
Path R3 to R2 to R4. Segment list 16002, 16004. Aggregate metric 20, two hops. The YELLOW tag is required on every link, so the direct link is out and the controller routes through R2, with no metric changed anywhere in the network. Policy R3_R4_YELLOW, affinity-set YELLOW_ONLY.
Reserve 40 Gbps, a bandwidth constraint
Path R3 to R2 to R4. Segment list 16002, 16004. Aggregate metric 20, with 40 Gbps held. The same path with capacity attached: the controller checked both links could carry 40 Gbps before installing anything and recorded the reservation in its own ledger. Policy R3_R4_YELLOW, bandwidth 40 gbps.
Pick the exit peer, egress peer engineering
Path R3 to R2 to AS 101. Segment list 16002, 25600. Aggregate metric 10, one hop plus the exit. 25600 is the BGP Peer SID that R2 allocated for its peering with AS 101, so the segment list ends by naming an exit. Policy R3_R2_EPE.
That exit, on blue links, affinity plus egress peer engineering
Path R3 to R1 to R2 to AS 101. Segment list 16001, 16002, 25600. Aggregate metric 20, two hops plus the exit. Both constraints at once: the exit is still AS 101, and the path to it must stay on BLUE links, so the controller goes the long way through R1. Policy R3_R2_EPE_BLUE, affinity-set BLUE_ONLY.

Every segment list, metric and policy name here comes from the joint IP Infusion and Vegvísir application note. Each is shown there as live output from show traffic-eng policy <name> detail on the controller. Traffic Dictator syntax is documented at vegvisir.ie/documentation.

Egress peer engineering

The ingress router can choose which peering the packet leaves through.

Traffic engineering usually stops at your own border, whereas egress peer engineering extends one hop beyond it, so the ingress router chooses which peering the packet leaves through. Where transit costs more than peering, that choice reduces cost.

Bandwidth-aware egress peer engineering after a peering failure Four ingress routers each send 30 Gbps toward the same destination autonomous system, load balanced over two private peerings of 100 Gbps each. One peering fails. Without bandwidth awareness all 120 Gbps lands on the surviving 100 Gbps peering and congests it. With a bandwidth constraint the controller admits only what fits and sends the remainder over the transit uplink instead. 4 INGRESS ROUTERS, 30 Gbps EACH 120 Gbps in private peering A 100 Gbps, down private peering B 100 Gbps, 90 admitted 3 policies fit transit uplink second candidate path 4th goes here AS 200

A worked example of the mechanism, not a lab measurement.

Four routers each push 30 Gbps toward one destination, balanced across two private peerings of 100 Gbps that are preferred because they cost less than transit. One of those peerings then fails.

With standard BGP the whole 120 Gbps lands on the surviving peering, and every service crossing it degrades at once.

A bandwidth constraint makes the controller admit only what the peering can carry, so three policies land on the survivor and the fourth takes its second candidate path over transit.

The result is a small amount of transit spend, while everything else on the peering keeps running.

Every peering is given its own label

egress-engineering on the border router allocates a BGP Peer SID for that peering and advertises it, so the controller can put an exit at the bottom of a segment list.

Link affinity applies right up to the border

A BGP Peer SID carries no link attributes, so you assign an affinity and a bandwidth to the egress peer on the controller and it matches them against the advertised SID.

Use the closest exit that has spare capacity

A policy with a null endpoint asks for the nearest suitable exit, so the controller picks the qualifying exit closest to the head-end and traffic leaves before crossing your backbone.

Controller capability, outside the joint validation: null endpoints need colour steering, and the joint lab used service loopback steering throughout.

A failed peering is visible in the policy state

When the neighbour goes down the peer SID is withdrawn and the egress policy fails, and that failure is reported in the policy state.

Built and tested together

What the joint lab exercised, and what it returned.

IP Infusion and Vegvísir Systems built the design together and published it. The table below lists each capability exercised, together with the result each test produced.

RoutersUfiSpace S9510-28DC
Router softwareOcNOS 6.6.0
ControllerTraffic Dictator 1.6
PublishedAugust 2025
Ten capabilities exercised in the joint validation.
Capability How it was driven Result
Topology export IS-IS level-2 database redistributed into BGP-LS on one router R3 exported 34 pieces of link-state information: 5 nodes, 10 links, 19 prefixes. The controller's own table showed them received.
Explicit path Strict hops named in the policy, plus a 2 Gbps reservation Segment list [16001, 16002, 16005] installed.
Bandwidth constraint A bandwidth figure carried on the candidate path A 2 Gbps reservation on the explicit-path policy was checked at computation time and recorded in the controller database, visible as reduced unreserved bandwidth on every link of the path. The affinity policies used the same mechanism at 40 Gbps.
Link affinity Two policies between the same pair of routers, one per admin group BLUE produced [16004] at metric 10, YELLOW produced [16002, 16004] at metric 20. Same endpoints, different paths, no metric changes anywhere.
Service mapping Two L3VPN customers on separate service loopbacks Each VRF resolved over its own policy. A ping in VRF101 was captured on the transit router and carried the expected transport and VPN labels.
Path diversity Two policies placed in the same disjoint group The two policies always took different links, with no affinities and no explicit paths configured at all.
ECMP and anycast SID A shared prefix SID advertised by two routers with the node flag cleared Two segment lists collapsed into one, which saves forwarding table space.
Egress peer engineering A BGP Peer SID allocated for an external peering and steered to Segment list [16002, 25600], where the last label is the peering rather than a router. Adding an affinity produced [16001, 16002, 25600].
Controller failover Primary controller stopped with policies delegated to it The router redelegated every policy to the second controller. No state was synchronised between the two.
Total controller loss All controllers stopped Policies withdrawn, the service routes resolved over IS-IS segment routing, next hop unchanged. The replacement entries were installed and active when the table was read.

The validation ran on one platform. The tested architecture is standard IS-IS, BGP-LS and PCEP, so the design travels, and platform and release support should be confirmed against the hardware compatibility list and the feature matrix for the box you have in mind.

Failure behaviour

What happens when a controller is lost, and when all of them are.

Traffic continues to flow in both cases. If one controller is lost, the routers move their policies to another one, and if all of them are lost, the services fall back to the shortest path the IGP was already computing.

If one controller is lost, the routers redelegate the policies themselves

Each policy is delegated to the controller that created it, and when that controller stops answering, the router redelegates it to another. Because the mechanism runs in the router rather than between the controllers, the controllers never share state, so adding a third one costs nothing in state synchronisation.

PCEP delegation moving from a failed controller to a surviving one Two controllers sit above one router. The policy is first delegated to the primary controller. When the primary stops answering, the router withdraws that delegation and redelegates the same policy to the second controller, which continues to update it. Nothing is synchronised between the two controllers. Controller A stopped answering Controller B now holds the policy OcNOS head-end keeps forwarding throughout delegation withdrawn redelegated by the router no state shared between them

If every controller is lost, everything resolves over IS-IS again

The policies are withdrawn and the service routes resolve over IS-IS segment routing instead. The BGP next hop stays the same.

R3, before the controllers were stopped
P>  172.16.101.4/32   out-label 3       out-intf cd1   nexthop 10.100.3.2
P>  172.16.102.4/32   out-label 3       out-intf cd0   nexthop 10.100.6.4
P is an SR Policy entry. Two services, two different engineered paths. Columns condensed from the full show mpls forwarding-table output.
R3, after the controllers were stopped
B>  172.16.101.4/32   out-label 24962   out-intf cd0   nexthop 4.4.4.4
B>  172.16.102.4/32   out-label 24963   out-intf cd0   nexthop 4.4.4.4
B is a BGP entry resolved by IS-IS segment routing. The BGP next hop of the VPN routes is unchanged. What changes is how it resolves, over IS-IS segment routing instead of over a policy, which is why the outgoing label and interface differ. Both entries were 16 seconds old when the table was read. Columns condensed from the full output.
SR-MPLS, TI-LFA and Flex-AlgoThe underlay itself: labels, fast reroute and latency planes in the IGP. RSVP-TE and where it still winsSignalled bandwidth admission, DS-TE and auto-bandwidth, and when to keep them. Designing the SR coreDual planes, SRGB planning and the peering edge this rides on. SRv6 in OcNOSThe IPv6 data plane, including where it fits alongside SR-MPLS.
The configuration, both sides

On the router side the configuration is ordinary IS-IS and BGP, with a single PCEP block added.

These are excerpts from the joint validation, with comments added. Because Traffic Dictator uses an industry-standard CLI, the controller configuration is as readable as the router configuration, so one engineer can work across both halves.

Two protocols can bring a policy down to the router

PCEP Validated pairing

It is stateful, so the controller knows whether the router installed the policy and is forwarding on it, and it needs one session per head-end. This is the option the joint validation used.

BGP SR-TE Fewest sessions

Policies are carried as BGP routes, so they ride your existing route reflectors instead of needing a session to every head-end. On a large network that is the difference between a handful of sessions and hundreds of them.

OcNOS · BGP-LS export 
! feed the IS-IS link-state database into BGP
router isis 1
 distribute bgp-ls
!
router bgp 65002
 bgp router-id 3.3.3.3
 neighbor 192.168.123.1 remote-as 65001
 !
 address-family link-state link-state
 neighbor 192.168.123.1 activate
 exit-address-family

What each line does

  1. distribute bgp-ls is the whole export: IS-IS hands its database to BGP.
  2. The controller is just another BGP neighbour, in its own autonomous system.
  3. link-state address family carries topology. Three kinds of information cross it: Node, with system IDs and the segment routing global block; Link, with metric, bandwidth, admin group and adjacency SID; and Prefix, with prefixes and their SIDs.
  4. Only one router needs this configuration, because it re-advertises the link-state database that the whole IS-IS level has already given it.

Excerpted from the joint application note, IP Infusion and Vegvísir Systems, August 2025. Verify current syntax at documentation.ipinfusion.com.

Traffic engineering, answered

What is an SR-TE controller?
An SR-TE controller is a control plane element that computes segment routing traffic engineering paths on behalf of routers and installs them. It learns the topology, applies constraints such as bandwidth, link affinity and path diversity, then hands each head-end router a segment list.
Do I need a controller to run segment routing?
No. Segment routing runs without one: IS-IS or OSPF with SR extensions gives you connectivity, ECMP and TI-LFA local protection on its own, and Flex-Algo carves latency and affinity planes in the IGP with no controller at all. A controller is what you add for an explicit hop-by-hop path, a network-wide bandwidth reservation, a chosen exit peer, or two services guaranteed not to share a link.
Is Traffic Dictator mandatory, or can we use a different controller?
OcNOS speaks standard BGP-LS and PCEP, so it is not tied to one controller, and Traffic Dictator is multi-vendor for the same reason. The joint design pairs OcNOS with Traffic Dictator because IP Infusion and Vegvísir built and published it together, with the configuration and lab results on both sides. Bring your own controller and the router half is unchanged.
Who supplies and supports each half of this solution?
Each half comes from its own vendor. IP Infusion supplies the routers and OcNOS as one integrated system, and Traffic Dictator comes from Vegvísir Systems. The two were designed and tested together and published as a joint application note. Talk to us and we will help you scope both sides and put you in touch with Vegvísir for the controller.
Do I have to replace my existing routers to add an SR-TE controller?
Usually not. A router that supports PCEP or BGP SR-TE can take policies directly, so the controller is introduced at the head-ends that support it while the rest of the network keeps forwarding on IS-IS segment routing exactly as it does now. Equipment that supports neither simply is not a head-end, and it does not need to be, so a mixed estate stays in scope while you replace boxes on your own schedule.
Can we migrate from RSVP-TE without rebuilding our services?
Yes, and that is why the joint design uses service loopback steering rather than colour steering. PCEP carries both RSVP-TE tunnels and segment lists, and service loopbacks work with either, so services can be moved onto segment routing one at a time without changing their configuration. Colour steering is the more flexible model once the migration is finished.
Can the bandwidth reservation follow measured traffic?
Not today. A policy carries the bandwidth figure you set, and the controller verifies the capacity is free before it installs the path, which is the behaviour the joint lab exercised at 2 Gbps and at 40 Gbps. Reservations that resize themselves from measurement are an RSVP-TE behaviour, covered on the MPLS-TE page. Traffic Dictator does not do it today, and Vegvísir Systems develops it on customer request, so tell us early if your network needs it.
Is SRv6 traffic engineering supported in this design?
The joint validation covered SR-MPLS only, and the limit was the router release under test rather than the controller. OcNOS supports the SRv6 data plane in its own right, so confirm SRv6 traffic engineering against the specific release and platform you have in mind.
Take it with you

Want the lab in full?

A short, technical download that goes further than this page: the segment routing application note.

Application Note

Segment Routing Application Note

The full engineering write-up: the validated lab, every configuration on both sides, the BGP-LS and PCEP session output, the computed segment lists, and the failure tests, step by step.

Get the application note
Next step

Take it to a proof of concept.

Vegvísir Systems publishes Traffic Dictator for evaluation and proof of concept work without a licence, limited to 100 policies, and OcNOS is available as a virtual machine. Tell us what you want to steer and we will scope it on the right pair, then size the production build.

Get the OcNOS virtual machine Talk to an engineer How to buy