Segment Routing in UCloud Backbone Network: Architecture Evolution and Implementation

Background and challenges – With the rapid adoption of cloud services, customers demand flexible, high‑performance connectivity for workloads such as web front‑ends, video conferencing, and data storage. Traditional MPLS backbones cannot meet requirements for dynamic cloud‑to‑cloud, VPC, and cross‑region traffic, leading to six key challenges: flexible service provisioning, hybrid networking, QoS guarantees, simplified deployment, bandwidth utilization, and intelligent, reliable scheduling.

DCN network rapid iteration – UCloud’s data‑center network (DCN) grew from a few zones in three cities to 31 zones across 25 regions worldwide, prompting upgrades from single‑zone to multi‑zone and multi‑region architectures. This growth introduced high‑bandwidth, low‑latency demands on the MAN and backbone layers.

Global dedicated‑line resources – Over 500 CDN nodes and dedicated lines connect all regions, providing end‑to‑end stability, high availability (99.99% SLA), and traffic visibility through point‑to‑point protection and SR‑TE‑based fast failover.

Backbone evolution history

• Backbone 1.0 (pre‑2018) : Built on MPLS, with M‑Core devices, ISIS for IGP, IBGP for inter‑region routing, and BGP ADD‑PATH for ECMP. Goals were region‑level DCN interconnect and UDPN‑based VPC peering, but challenges included tight coupling of MAN and backbone, complex provisioning, and lack of intelligent traffic scheduling.

• Backbone 2.0 (pre‑2020) : Introduced an Underlay/Overlay split using VXLAN + BGP EVPN for a large L2 fabric, enabling tenant isolation without MPLS‑VPN. While it improved layering and flexibility, it suffered from high VXLAN overhead, limited L3VPN support, and no traffic‑engineering capabilities.

Segment Routing fundamentals – SR inserts an ordered list of segments (Segment‑list) into packet headers, allowing the source node to dictate the path without requiring per‑hop state. Types of segments include Prefix‑SID (global, ECMP‑aware), Node‑SID (router‑ID based), Adjacency‑SID (link‑specific, non‑ECMP), and Anycast‑SID (global anycast with ECMP).

SR‑Policy (SR‑TE) features – SR‑Policy replaces traditional tunnel interfaces with a segment list that encodes explicit or dynamic paths. A policy is identified by a head‑end, a 32‑bit color (representing intent such as low‑latency), and an endpoint address. Policies can be computed statically (CLI/Netconf) or dynamically via PCEP, supporting automatic re‑computation on topology changes.

Automatic traffic steering – BGP routes are colored and installed into SR‑Policy entries, enabling fine‑grained, high‑performance steering without complex configuration. This mechanism works for both intra‑domain and inter‑domain scenarios.

SR‑TE vs. LDP/RSVP‑TE – After detailed comparison, UCloud selected SR‑TE for the new backbone because it offers simpler control‑plane operations, better scalability, and native traffic‑engineering capabilities while still using MPLS encapsulation for forwarding.

Conclusion – The article outlines the evolution from a basic MPLS backbone to a Segment Routing‑enabled architecture that addresses the rapid growth of cloud workloads, providing intelligent, reliable, and programmable network services across UCloud’s global infrastructure.