Segment Routing: Inside a New SDN TechnologySegment Routing: Inside a New SDN Technology

Will this new packet-forwarding mechanism replace OpenFlow for software-defined networking?

IP packet forwarding techniques traditionally have relied on taking the shortest path to the destination IP address. But forcing different traffic types on different paths is often useful depending on application type. For example, real-time UC&C applications typically prefer low-latency, low-jitter paths, while large data applications prefer high-bandwidth paths with low packet loss. Segregating traffic according to application need is very useful. However, policy routing is painful to set up, and is static (or perhaps nearly dynamic, if you have excellent automation tools).

We've also found the need to use policy when arbitrating among multiple applications that want the same service class. Which application gets the bandwidth when a bandwidth allocation for a traffic class is full? How does the network tell the applications that no bandwidth remains in the desired traffic class? That's where software-defined networking (SDN) is desirable -- traffic forwarding selected by an application or by a traffic policy manager (see the International Multimedia Telecommunications Consortium's whitepaper on automating UC quality-of-experience services). The OpenFlow protocol has captured interest for its ability to apply policies dynamically. Now a relatively new technology offers an alternative approach: segment routing (SR).

What Is Segment Routing?
SR is an SDN technology whose packet-forwarding mechanism serves as an alternative to OpenFlow. Created by Cisco, SR is making its way through the IETF standardization process. Several vendors are implementing it, and some customers are using it.

A team of experienced networking professionals took a close look at SR in a recent one-day Tech Field Day event. You can find lots of documents about SR on the Internet, but I found that many of them gloss over important details (like assigning labels to each router/node). For some good, detailed background on SR, see:

SR uses a path-label mechanism (Multi-Protocol Label Switching, or MPLS, labels in IPv4 or a path shim header in IPv6) to specify the route packets must take through a network. The packets must go through each node in the label path, but may go through other intermediary nodes as well, making it function much like the IPv4 loose-source-routing mechanism. The loose-source-routing mechanism reduces the number of labels needed to route a packet to its desired destination. The network forwards packets along the shortest path between nodes in the label list.

Each router is a node and, unlike with MPLS, SR assigns each node a fixed, 20-bit label (work on developing a mechanism for assigning and maintaining labels without resorting to a spreadsheet is underway). The labels are fixed, not dynamic like they are in MPLS Layer 3 VPNs, making troubleshooting easier. Labels and topology information propagate throughout the network by extensions of one of three routing protocols: Intermediate System to Intermediate System, Open Shortest Path First, or Border Gateway Protocol. SR requires no label distribution protocol, thus removing the need for synchronization between the routing protocol and a label distribution protocol.

With SR, an external system, such as a path computation element (PCE), defines paths. A PCE would be able to create paths that don't share topology or paths that separate real-time UC&C traffic from bulk data traffic. The PCE interacts with the routing protocol to obtain topology and other information for use in determining the set of labels to add to packets. As a result, the control plane in an SR system comprises the routing protocol running on the routers for collecting topology information and a PCE that uses that topology information to calculate paths for different applications.

When the PCE determines that a flow should traverse a path other than the shortest path, it sends a label stack entry to the ingress router for that flow. No other routers need to receive any information from the PCE, making SR a very efficient protocol, in terms of programming the forwarding information.

How Do SR and OpenFlow Differ?
In OpenFlow, the OpenFlow controller must load forwarding table entries into switches along the path from source to destination. SR is different in that the PCE encodes the forwarding path as a loose source route in an MPLS header that is inserted only at the ingress router. Instead of pushing a flow entry to all the switches in a path, SR programs an MPLS label stack on the ingress router for each flow.

Another difference is that an OpenFlow controller collects neighbor adjacency information from all the switches/routers and uses that information to make its forwarding decisions. The SR PCE relies on a routing protocol to collect topology information and to propagate labels. The SR mechanism uses routing protocols that run on the network hardware, potentially making it more difficult to deploy new versions of those protocols. The level of difficulty depends on the system architecture.

SR needs better documentation. Reading RFCs is a difficult way to learn a new protocol. Good architecture and functional documentation are needed to make SR accessible to more people.

It's Good to Have Alternatives
SR is the first alternative I've seen that provides functionality similar to SDN. SR needs a lot more development before it gets to the point that it can provide the bidirectional application-to-network communications demonstrated with some OpenFlow products. On a more positive note, SR looks like it may be more efficient than the OpenFlow mechanism of pushing flow entries to multiple network devices.

As with any new technology, it will take a few years to architect the complete system. Network staff will also need to gain a good understanding of the new technology and how to best deploy it. For now, it is good to know that you have alternatives.