Evaluate Weigh the pros and cons of technologies, products and projects you are considering.

How segment routing could be a boon to SDN

Segment routing could prove to be a compelling alternative to OpenFlow, but more work needs to be done before it becomes a mainstream technology.

Segment routing, or SR, is an innovative alternative to OpenFlow and other platforms underpinning software-defined...


You can think of SR as a modern form of loose-source routing, because packets may traverse other routers in addition to those specified in the segment route.

What's so great about segment routing? First, its configuration is much simpler than the alternatives -- typically only a few lines. Next, there is less state stored in the network. Less state means there is less information that needs to be communicated between network devices, making them more efficient and less complex. Finally, the complex state information is maintained within a path computation element (PCE), which is like a logically centralized SDN controller. The PCE is where network policies are implemented for determining the best path through the network. That path might require a specific topology be followed, such as a low-latency path. Or, the path may require a specific service chain be followed, such as traversing a load balancer or firewall.

SR provides fast failover to alternate paths when a network or device failure occurs. Topology-independent, loop-free alternate paths are calculated -- assuming the topology includes a loop-free alternate path. Failover is on the order of 50 milliseconds, which is on par with all the other failover mechanisms of the past.

Application interface to path selection

One of the most important features of SDN is the ability for the network and applications to share information with each other. An application that needs specific network characteristics -- such as latency, jitter, packet loss or minimum bandwidth reservation -- can communicate those requirements to the central network controller. The controller then determines if the network can support the flow and the path the flow should take. If the network can't support the application's flow, the application can adapt to what the network can provide. Otherwise, the network controller, or PCE in this case, makes a reservation for the application. One of the neat things about segment routing is the application doesn't need to wait for the network before starting to send data. It can begin using the shortest path route immediately with the default quality-of-service settings. The PCE can dynamically reprogram the path by setting the required label stack in the ingress router.

What's so great about segment routing? First, its configuration is much simpler than the alternatives -- typically only a few lines.

A simple example of an application interacting with the network is with unified communications and collaboration. The UCC controller can request service for a new call, and the network can perform call admission control based on the available bandwidth between the endpoints.

That said, it will take time before common applications begin to communicate with the network. The APIs will need to be well-defined, and the application vendors will need time to incorporate the new technology. Until then, tools like WAN automation and optimization will be assisting the unmodified applications.

There will be times when multiple applications are simultaneously vying for the same class of network service. One way to overcome this problem is to use a middleware module that uses a policy to resolve resource conflicts. An administrator defines policies that are used to determine which of two systems gets the limited network resources. I think it is wise to incorporate a policy module to provide much simpler controls over network and application interaction.

An introduction to segment routing

A good introduction to segment routing is this Cisco white paper, which covers the implementation of the technology. Another helpful guide is this 12-minute video by Clarence Filsfils, a Cisco fellow. Finally, Cisco discussed how segment routing works with its WAN automation engine in this presentation.

Is segment routing real?

At a segment routing Tech Field Day held earlier this summer, Cisco disclosed that three customers are using SR within their production networks: Wal-Mart, Comcast and Microsoft. Each of these customers gave a presentation on its use of the technology at the conference. The presenters saw themselves as adopting a technology that was reasonable to implement, while giving them a competitive edge.

In my view, SDN is happening and segment routing is an alternative to OpenFlow. SR provides the fundamental characteristics that are needed, such as packet forwarding that is more flexible than destination IP address forwarding.

An API allows applications to exchange information with the network, including asking for classes of service and getting information about changes in the network. Some parts of it will be centralized, because that's what is needed to arbitrate between multiple applications that are requesting the same level of service. Finally, I expect to see automation and simpler network configuration.

Next Steps

What happened to OpenFlow in SDN?

Making sense of SDN and centralized controllers

A quick look into segment routing

This was last published in August 2016

Dig Deeper on Emerging software-defined networking protocols



Find more PRO+ content and other member only offers, here.

Join the conversation


Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

How do you think segment routing will affect SDN?
SDN for the WAN is a very different proposition from SDN in the Datacenter or even SD-WAN overlays. It is unlikely for WAN devices (routers) to transition purely to Openflow based forwarding so the goal of centalising the control plane in its entirety is unlikely to be reached. So we could be left with a hybrid scenario where a central node (controller) is aware of all paths and able to influence paths throughout the network but with a local contro plane still embeded in each router. In answer I think they will be complementary but this could serve to standardise protocols for the 'underlay'