Wiki source code of SR-MPLS

Hide last authors
EANTC Bot 1.1 1 (% class="row" %)
2 (((
3 (% class="col-xs-12 col-sm-7 test-report-content" %)
4 (((
5 ----
6
7 Segment Routing over MPLS (SR-MPLS) is based on MPLS but uses segment identifiers (SIDs) instead of traditional MPLS label distribution protocols to create paths. SR-MPLS provides a more scalable and flexible network architecture, allowing operators to steer traffic dynamically. Traffic engineering policy support built into SR-MPLS helps accommodate various demands, like low latency or high bandwidth. At the same time, SR-MPLS runs on any equipment supporting MPLS without hardware chipset modifications, a significant difference from SRv6.
EANTC Bot 2.1 8 This year, we built our interoperability tests on the previous year's baseline and extended them to use cases such as SR-MPLS for 5G xHaul networks.
9 We focused on the design of 5G xHaul to see whether SR-MPLS could be a reliable transport for O-RAN components across the fronthaul, midhaul, and backhaul segments. We measured the latency for L3VPN and VPWS for different vendor scenarios, where DUTs dropped any best-effort traffic above 10Gbit/s, but high-priority traffic marked with DSCP/802.1p passed without issues. We tested PTP prioritization on access routers to ensure DUTs won't drop time synchronization packets.
EANTC Bot 1.1 10 We also tested SR-MPLS in an Inter-AS environment to see how Anycast SIDs guide traffic to the closest routing domain border router (ASBR). We ensured the egress label stack maintained the expected sequence for the packets to reach their intended destinations appropriately.
EANTC Bot 2.1 11 We evaluated traffic steering with SR-TE, validating how headend routers can direct flows according to colors/destinations for ingress and egress and IPv4 and IPv6.
12 Continuing our efforts for multi-vendor interoperability of Flex-Algos from 2024, we tested and validated the routers' capability to determine constraint-based paths(TE metric, link-delay, and Admin Group). We added new types of constraints, such as excluding links less than a specific capacity, exceeding the maximum allowed delay, and admin-group inclusion/exclusion, which is considered a "reverse affinity" functionality that checks link attributes in the reverse direction.
13 We evaluated Seamless BFD (S-BFD) for path status monitoring. Using S-BFD, the devices under test could detect failures and swiftly failover to a backup path based on SR-TE policies. DUTs can use backup paths based on network performance parameters, such as bandwidth and delay. Such configuration options are helpful in situations where the standard IGP metric does not serve well.
14 Other essential tests included multi-vendor SR-MPLS connectivity via 400ZR/ZR+ pluggables, including support of topology-independent loop-free alternate (TI-LFA) with micro-loop avoidance for local and remote protection and Shared Risk Link Group (SRLG) scenarios. Not all vendors participated in every test case; however, many different platforms worked well together. These evaluations confirmed the operational advantages of SR-MPLS in large-scale deployments.
EANTC Bot 1.1 15 Finally, we reconfirmed the multi-vendor interoperability of L3VPN services over SR-MPLS transport in new combinations; both IS-IS and OSPF were used to advertise SIDs.
16
17 The following test cases have been executed for this test area:
18
19 {{container cssClass="toc-list"}}
20 {{include reference=".Sidebar Nav"/}}
21 {{/container}}
22
23 (% id="prev-next-links" %)
24 |[[< Previous>>doc:Main.Multi-Vendor MPLS & SDN Interoperability Test Report 2025.Orchestration and Automation.NETCONF and gNMI basic operations]]|[[Next ~>>>doc:L3VPN over SR MPLS]]
25 )))
26
27 (% class="col-xs-12 col-sm-5 test-report-sidebar" %)
28 (((
29 {{box}}
30 {{include reference="Main.Multi-Vendor MPLS & SDN Interoperability Test Report 2025.Sidebar Nav"/}}
31 {{/box}}
32 )))
33 )))