JNT Visual - Fotolia
Segment routing, or SR, is an innovative alternative to OpenFlow and other platforms underpinning software-defined networking.
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.
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.
What happened to OpenFlow in SDN?
Making sense of SDN and centralized controllers
A quick look into segment routing