On Segment(ed) Routing

 
Cloud Networking, , , , ,

Traffic Engineering On Segment(ed) Routing Using MPLS and IPv6

Segment Routing is one of the hottest technologies being considered to transform the way packets are handled in critical networking infrastructures. Whether it is in the core of the internet, within data centers, or between data centers, Segment Routing is seen as a simpler way to control networks, program packet routes and processing, and implement traffic engineering policies.

A closer look shows that essentially Segment Routing implementations are segmented depending on the underlying technology. Segment Routing architecture has been specified by the IETF (RFC 8402), but the actual implementation in the data plane, which carries the traffic eventually, has been done over two fundamentally distinct technologies – MPLS and IPv6. Thus, one architecture, but a choice between two data planes. The interesting part is that not only do these two data planes use different definitions of the segments, but they keep them in opposite orders (!!!).

Segment Routing Differences: To Put Things Visually

The MPLS data plane architecture allows a packet to carry multiple “labels”, acting as segments identifiers, or SIDs if you’d like. So does IPv6, through a Segment Routing Header (SRH), which is an extension to the IPv6 header; the SRH carries multiple segments as well.

And this is where the fun stuff begins:

The MPLS data plane places the next segment (represented as a label) in the stack closest to the MAC header (i.e. beginning of the packet), and “pops” (removes) the segment after it is used to determine the next hop.  Thus the “current” segment and the next segment are always in the same “place” in the packet relative to the MAC header:

MPLS segment routing keeps the segment labels in order with the current/next label at the front of the packet, closest to the MAC header

On the other hand, IPv6 Segment Routing (also known as SRv6) carries the “current” segment as an IPv6 destination address, with the rest of the segments in the SRH, such that the last segment is the closest to the MAC header, and the next segment in the stack furthest from the MAC header, at least to begin with. Its location in the SRH varies, and can be found using a pointer (called “Segments Left”) that indicates the next segment location, and as the packet traverse the next-segment pointer is updated without removing any of the segments from the stack:

Segment Routing with IPv6 or SRv6 keeps the segments in the reverse order as it’s done with MPLS, and IPv6 segment routing doesn’t drop segments as they are used.

How Would MPLS and IPv6 Affect My Network?

These two different underlying technologies make a big difference when considering high-speed data plane silicon to support segment routing. For MPLS data plane, most switch ASICs were not built with segment routing in mind, while others, such as the Mellanox Spectrum switch, have much better capabilities. This includes additional set of Segment Routing oriented actions set, deep parsing that enables the use of entropy from above the MPLS stack, unique data structures to scale segment routing for data centers, and enormous label tables scalability. For more details see my previous blog: “Building a Simple, Scalable MPLS Segment Routing Network”.

For Segment Routing over IPv6 (SRv6), most of the switch ASIC implementations simply lack the ability to look deep enough into the packet, see the multiple segments, and use a segment that is located at an arbitrary offset within the SRH. The good news is that new data plane architectures are evolving and making their way into the market, enabling efficient and high-throughput implementations that support these requirements, and will drive market adoption further for MPLS-SR, but also SRv6. The ability to deploy these products in the data centers will enable network architects and administrators to apply traffic engineering and program the network inside IPv6 supported networks. Segment Routing, with all of its benefits, will no longer be a secret tool accessible only for the ones who run MPLS.

I‘d be glad to get your inputs, and talk to me if you’re interested to hear more!

 

About Barak Gafni

Barak Gafni is a Staff Architect at Mellanox Technologies, focusing on enabling the most scalable, agile and simple networks of tomorrow. He joined Mellanox at 2009, and has 12 years of experience in the networking industry. Barak holds a B.Sc. in EE from the University of Tel Aviv (Cum Laude), has co-authored multiple IETF RFCs and holds several patents in the space of networking.

Comments are closed.