Your Network's Edge®
Blog Post
You are here
Segment Routing
Apr 15, 2019
IP forwarding is typically based on destination addresses (and perhaps the DSCP), but sometimes we need better control over the precise path a packet travels to its destination.
For example:
- in data centers we often need to ensure packets traverse particular nodes (in order),
- for security reasons we may need to avoid particular router(s),
- policy-based routing overrides default routing paths to attain specific QoS goals,
- we may need paths with very special characteristics (e.g., ultra-low delay).
These and related cases are frequently relevant for transport of OTT, cellular backhauling, and misc. wholesale services.
Source Routing
For such cases, the IP protocol suite provided a mechanism called Source Routing. In IPv4 this feature utilizes the IP options field, while the IPv6 version uses the type 0 routing header extension (Rh0). In both cases, Source Routing operates by inserting a sequence of router addresses into packet headers. The routers along the way forward according to these explicit addresses, rather than according to the Forwarding Information Base set up using the routing protocols.
Yet source routing can be problematic. It significantly complicates the processing algorithm used for forwarding. More importantly, it introduces several security concerns that have led to source routing being considered evil:
- DoS attacks – the attacker forces packets to traverse selected routers, thus overloading them,
- amplified DoS attack – the attacker forces packet to oscillate between 2 selected routers,
- infiltration attack – the attacker bypasses Access Control Lists protections by forwarding through a permitted waypoint.
The IETF has not completely deprecated the use of Source Routing, but highly recommends that it be disabled. In practice, core Internet routers routine drop packets with most IP options, and the Linux kernel forwarding engine no longer processes Source Routing.
But without Source Routing, how can we achieve policy-based routing and the other goals of consequence that we enumerated? There seem to be two alternatives.
SDN
Software Defined Networking. By obviating routing protocols and utilizing a centralized path optimizer, SDN gives the network administer full control over routing. Particular flows can be configured to traverse arbitrary paths. Carrier Ethernet configured using a Network Management System, and MPLS-TE using a Path Computation Element, are essentially the same as SDN from this point of view. However, SDN too suffers from disadvantages. It necessitates relatively major architectural changes (unless used as an overlay network). More importantly, many species of SDN introduce security issues of their own! For example, a programming bug (not to mention an intentional attack) in OpenFlow and similar southbound interfaces may impact uninvolved services, which may have been correctly running for years.
Segment Routing
Segment Routing. Segment routing is somewhat similar to Source Routing, but does not suffer from the aforementioned security concerns. A Segment Routing path is specified by the ingress router, not by the source host, thus blocking Source Routing attacks (unless the ingress router has been compromised). The SR header consists of a stack of segment IDs (SIDs) which serve the function of the sequence of addresses in source routing.
SR was originally devised for MPLS where it can be implemented with essentially no changes to the existing forwarding plane (and only minor extensions to the routing protocols) by using the existing label stack to hold SIDs, and popping labels rather than swapping them. SR was afterwards defined for IPv6 (abbreviated SRv6) where the Segment Routing header comprises 128-bit SIDs and is situated between the IPv6 header and the layer 4 header.
Both SR and SDN can coexist with conventional networking. The focal difference between SDN and SR is that SDN is basically a control (or more precisely management) plane protocol that configures the forwarding plane (which can be a conventional one). SR works in the forwarding plane itself (although some control plane functionality is required for the ingress router to know what SR stack to insert into the packet). Stated another way, with SDN the network maintains per-application/flow state, while with SR the forwarding instructions are provided inside the packet itself. A consequence of this difference is that in SDN all the intelligence resides in the centralized controller (i.e., SDN switches are dumb, fast, and inexpensive) while SR burdens the ingress LER (and/or PCE) with digesting information from the routing protocols, preparing and inserting the label stack.
Significantly, SR is a safer way to achieve policy-based routing than SDN. Since the SIDs that steer the forwarding are carried in the packet itself, no error can impact alien flows. A bug or intentionally incorrect forwarding stack impacts only the forwarding of the packet itself, and not neighboring flows.
Network Programming
SR proponents like to call it network programming. This name refers to yet another way of thinking about SR. In this version the ingress LER encodes a list of instructions (e.g., each SID may consist of an address and function identifier), and each subsequent LSR interprets and executes one instruction. This effectively turns the network into a giant processor. When using SR for network programming, the SIDS may represent:
- Forward over link L
- Go to node N using the shortest path
- Apply function S
The catch-all function may involve applying some policy rule, checking some arbitrary field (e.g., application awareness, or network slicing), saving a timestamp into a metadata field, or even ensuring that a packet is forwarded within some specified time interval (to upper bound the latency, as in TSN/DetNet). In fact, any function implementable by the forwarding router (or collocated VM/container) can be executed.
Summary
To summarize, Segment Routing is yet another new forwarding paradigm, applicable to MPLS and IPv6 networks. Like source routing it enables policy-based routing, but unlike source routing it is not considered evil. Unlike SDN, it operates mostly in the forwarding plane, and for that reason may be safer. It also enables network programming, including performing generic functionalities to packets on their way from source to destination.
Packet forwarding strategies have been swinging back and forth between centralized approaches (like the original PSTN, Carrier Ethernet, PCE) and distributed approaches (like IP routing). With SDN and Segment Routing the dividing line between these two poles has become blurry. Perhaps after years of going back and forth, we can now only go forward.
It remains to be seen if Segment Routing is the chosen road, or yet another side path.
RAD products provide segment routing with MEF 3.0 certified telecom devices, ensuring secure, policy-driven network pathways for industrial IoT and 5G RAN. Our solutions support critical network infrastructures with robust edge computing, network demarcation, and diagnostics for network performance.
About RAD's Blog
We’ll be blogging on a wide range of hot topics affecting service providers and critical infrastructure network operators. Our resident experts will be discussing vCPE, Cyber Security, 5G, Industrial IoT and much, much more.