In our latest article on SRv6 written by our experts, we discussed the benefits of SRv6 compared to MPLS. If you haven’t seen it yet, click the following link: https://made4it.com.br/srv6-um-sucessor-do-mpls/
In this article, we’ll discuss how SRv6 works, compare control plane protocols, talk about the data plane, and also examine the main differences between SRv6 and MPLS. MPLS is a technology that is still widely used today, but its operational characteristics are very different from those of SRv6, which was designed not only as an evolution of MPLS but also to greatly simplify the operation of transport and related networks, adapting them to future needs while reducing network complexity.
Comparison between SRv6 and MPLS.
Before discussing how SRv6 works, let’s examine the main differences between it and the well-established MPLS. The table below shows the “before” and “now” scenarios, illustrating the evolution and simplification from MPLS to SRv6:
Source: IP Network eBook Series: SRv6, Huawei, Lanjun Luo
In MPLS (before), we see a “stack” of protocols and technologies. All of this is simplified in SRv6, where we can deliver the same functionality as MPLS but without relying on “label” signaling protocols (LDP/RSPV-TE). There is also a simplification of service types; in SRv6, these utilize EVPN and its excellent scalability to provide access and transport for services on the network. In addition to all this, SRv6 also meets today’s needs for programmability and scalability, which were previously not possible with MPLS.
SRv6 is not limited to “metro” networks or transport networks in “future” environments (5G/IoT). See the example below: in the “before” scenario, we need IP/VXLAN to transport data within DC1 and DC2, while on the backbone network we use MPLS with LDP, TE, or SR(MPLS).
Next, we have the “After” view of the SRv6 implementation with EVPN, showing how the scenario has been simplified. With SRv6 and EVPN, we are able to achieve what was previously possible only with a “stack” of various protocols, which placed a heavy load on processing resources and increased the complexity of the environment.
Source: IP Network eBook Series: SRv6, Huawei, Lanjun Luo
In addition to these benefits, since SRv6 uses native IPv6 components, this is extremely helpful in migration scenarios. Today, virtually all equipment supports IPv6 header forwarding, so the migration from a legacy environment (MPLS) to this new technology can be seamless and gradual, protecting the investment and ensuring minimal downtime in the environment.
Source: Implementation of IPv6 Segment Routing (SRv6) at VIVO – Nelson J. dos Santos Junior – Brazilian IPv6 Forum 2023.
SRv6 and its simplicity are a great asset for integrating large routing domains (such as when one company is acquired by another and those networks need to communicate and interoperate). With SRv6, we can integrate such networks using simple routing summarization, whereas MPLS required extensive planning and the use of techniques such as InterAS OPTION A, B, and C.
How SRv6 Works:
We know that in MPLS, we use LABELS between Layers 2 and 3 to determine how a packet should be routed across a network; however, all devices along the path must have the necessary protocols enabled (IGP/LDP/RSVP).
The image below shows the MPLS labels of a captured packet:
Source: SINGH, Arshdepp. “Fun with Revisiting MPLS Basics.” LinkedIn, May 23, 2020. Available at https://www.linkedin.com/pulse/fun-revisiting-mpls-basics-capturing-labels-wireshark-arshdeep-singh
Accessed on: April 22, 2024.
SRv6, on the other hand, uses an extension to the IPv6 header called the Segment Routing Header (SRH) to insert IPv6 addresses known as SIDs (segment identifiers) to identify the IPv6 routing segment:
Source: DayOne Intro SRv6, Juniper, HEGDE, Shaddha, et al. .
The SID represents a specific segment within a routing domain segment; it uses a 128-bit IPv6 address, also known as an SRv6 Segment or SRv6 SID. Compared to MPLS, we can say that the SID is the “label” that defines the transport path or service; however, in SRv6, we transform this into a unique IPv6 address that can be routed natively via IPv6 (much simpler, isn’t it? 😉)
Take a look at the structure of an SID:
Source: IP Network eBook Series: SRv6, Huawei, Lanjun Luo
Locator: This is the first part of the SID, which uses more bits. It serves a location function, representing the address of a specific SRv6 node. Once configured on a device, it is propagated throughout the SRv6 domain using an IGP, allowing other devices to locate that specific node.
Function: A part of the SID that designates an SRv6 function that is executed locally on a specific node. We commonly refer to this as a “program.” It is an instruction for routing packets within the network.
In this SID, we can specify, for example, an EVPN-VPWS or an L3VPN specific to this node.
Given that the SID is contained within the “locator” block—which is advertised by the IGP (ISIS/OSPF) within the SRv6 domain—all communication directed at this SID terminates specifically at this “node.”
One comparison we can draw here with MPLS is the use of a “label” to define a service such as an L2VPN via targeted-ldp. In SRv6, all we need to do is implement SID instructions for the service at the head-end and tail-end, and that’s it. The “nodes” that need to interpret the SIDs will encapsulate/decapsulate data accordingly, while the rest of the network simply forwards the IPv6 packets based on the IGP.
Argument (optional): Used to define relevant information, such as “packet flow” and “service information,” as well as to implement Split Horizon in EVPN VPLS CE multi-homing scenarios. It has also been used in SID summarization and simplification implementations (G-SRv6 and uSID), but discussing this is beyond the scope of this article; however, it will likely be covered in a future one.
As we mentioned earlier, data forwarding based on IPv6 routing takes place at the core of the SRv6 network.
For nodes that support SRv6 and have allocated SIDs, the headers and instructions contained therein are processed. As for nodes that do not support SRv6 (older and/or outdated equipment), they simply forward IPv6 packets based on the packet’s header and destination addresses, in conjunction with the IGP.
What about load balancing?
Good old ECMP using IPv6 packets. In theory, any device can implement ECMP simply by using its traditional hashes.
It’s theoretically plug-and-play. Want to start implementing SRv6? Just start with two PEs while the rest of the network is IPv6-only.
What about the control plane?
The MPLS control plane is really busy. We have the basic LDP, which establishes discovery and targeted sessions and is widely used in MPLS networks. To implement traffic engineering, we have the resource-intensive RSVP protocol, which has been extended to support label signaling, resulting in RSVP-TE. To improve scalability, we use MP-BGP and signal labels through it. And that’s not to mention the IGP—ISIS or OSPF—which are loaded with TEDB extensions. Below is a comparison table between the two:
As for SRv6, the control plane consists solely of IGP and, when necessary, BGP for all the services and features that MPLS currently provides, as well as the emerging demands of future networks.
For SRv6 to work, both IGP and BGP required extensions that are used to propagate information about Locators and SIDs. For each type of SRv6 service, there is a specific TLV to be signaled across the network.
As for BGP, the extension allowed SID addresses to be carried in update messages, thereby enabling the establishment of L2VPN and L3VPN services over the SRv6 network.
In the control plane as well, we benefit from source routing, where we can map the path to the destination right from the source, without having to maintain multiple signaling mechanisms and states across the network. Since SRv6 allows us to assign an SID to a “node” or “adjacency,” we can, from the head-end, specify the entire desired transit path for a data packet while the network simply forwards the data. Yes, the packet leaves the “source” with the entire path already written in the header, either manually (SRv6-TE) or with the support of external tools. This, combined with the ability for external controllers to monitor the network, enables intelligent, service-oriented, and extremely effective networks.
In conclusion, SRv6 offers us the following definition: simplification combined with a high degree of programmability.
Would you like to learn more about SRv6, or do you need help integrating this technology into your environment? Contact us and stay tuned for upcoming posts on our blog!
See you later!
