PaperlayerView exact revision on arXiv

Source-linked AI summary

Segment Routing: a Comprehensive Survey of Research Activities, Standardization Efforts and Implementation Results

Pier Luigi Ventre, Stefano Salsano, Marco Polverini, Antonio Cianfrani, Ahmed Abdelsalam, Clarence Filsfils, Pablo Camarillo, Francois Clad

arXiv:1904.03471v5cs.NI

TL;DR

IP networks face growing bandwidth, device, and service demands, motivating scalable routing architectures. This paper surveys Segment Routing through its standards, patents, research activities, implementations, and deployments. It identifies source routing as enabling Traffic Engineering and reviews SRv6 network programming, research directions, and mature Linux and VPP implementations.

  • Problem

    IP networks face growing bandwidth, device, and cloud-service demands, while MPLS-TE has scalability limitations from explicit per-hop state and limited ECMP exploitation.

  • Method

    The paper provides a tutorial and comprehensive survey covering Segment Routing architecture, standardization, patents, research activities, implementations, deployments, and future directions.

  • Results

    The survey covers about 90 SR research papers, identifies relationships between SR features and research topics, and finds Linux and VPP open-source solutions mature for SR experimentation.

  • Takeaways & Limitations

    Source routing is identified as a key enabling feature for Traffic Engineering, while SRv6 is presented as a promising implementation for future research and network programming.

Abstract

from arXiv · show

Fixed and mobile telecom operators, enterprise network operators and cloud providers strive to face the challenging demands coming from the evolution of IP networks (e.g. huge bandwidth requirements, integration of billions of devices and millions of services in the cloud). Proposed in the early 2010s, Segment Routing (SR) architecture helps face these challenging demands, and it is currently being adopted and deployed. SR architecture is based on the concept of source routing and has interesting scalability properties, as it dramatically reduces the amount of state information to be configured in the core nodes to support complex services. SR architecture was first implemented with the MPLS dataplane and then, quite recently, with the IPv6 dataplane (SRv6). IPv6 SR architecture (SRv6) has been extended from the simple steering of packets across nodes to a general network programming approach, making it very suitable for use cases such as Service Function Chaining and Network Function Virtualization. In this paper we present a tutorial and a comprehensive survey on SR technology, analyzing standardization efforts, patents, research activities and implementation results. We start with an introduction on the motivations for Segment Routing and an overview of its evolution and standardization. Then, we provide a tutorial on Segment Routing technology, with a focus on the novel SRv6 solution. We discuss the standardization efforts and the patents providing details on the most important documents and mentioning other ongoing activities. We then thoroughly analyze research activities according to a taxonomy. We have identified 8 main categories during our analysis of the current state of play: Monitoring, Traffic Engineering, Failure Recovery, Centrally Controlled Architectures, Path Encoding, Network Programming, Performance Evaluation and Miscellaneous...

I. INTRODUCTION

Segment Routing applies loose source routing by encoding ordered instructions in packet headers, reducing core-node state for engineered paths and supporting complex services. This survey reviews SR architecture, evolution, standardization, patents, research, implementations, and deployment activity, with particular attention to SRv6.

  • Architecture: Segment Routing encodes ordered instructions called segments in packet headers to steer forwarding and packet processing.Segments may impose topological requirements, such as traversing a node, or service requirements, such as executing an operation.
  • Architecture: SR requires data-plane support for carrying and processing segment lists, plus control-plane mechanisms for allocating and distributing segment identifiers.SR-MPLS and SRv6 provide the two data-plane instances described in the survey.
  • Evolution and motivation: SR-MPLS preserves the established MPLS forwarding plane, whereas SRv6 uses IPv6 and supports network programming for complex services such as Service Function Chaining.SRv6 can combine overlay and underlay functions and is presented as attractive for new or evolving network architectures.
  • Control plane: SR control planes may be distributed, centralized, or hybrid, with controllers or routing protocols associating traffic with SR Policies.The centralized approach lets an SR controller allocate segments, select policies, and configure nodes.
  • Survey scope: The survey covers standardization, patents, research activities, implementations, deployments, lessons learned, future directions, and approximately 900 related patents.Its research review covers 88 scientific papers in the introduction's roadmap, while the historical review notes about 900 registered patents.
  • Evolution and motivation: SR originated partly to address MPLS-TE scalability limitations by removing per-flow state along engineered paths and exploiting ECMP within segments.MPLS-TE requires explicit state at all hops and does not easily exploit ECMP under its per-connection steering model.

A. MPLS data plane (SR-MPLS)

SR-MPLS implements Segment Routing by encoding segment lists as MPLS label stacks without changing the MPLS forwarding plane. Label mapping depends on each router’s SRGB, and identical SRGB ranges simplify operation across the domain.

  • SR-MPLS operation: SR-MPLS instantiates an SR Policy through an MPLS label stack, mapping PUSH, NEXT, and CONTINUE to classical MPLS forwarding functions.Segment IDs in the segment list are inserted as MPLS labels, and no MPLS forwarding-plane change is required.
  • SRGB mapping: Each router may advertise an SRGB label range, so global segment indexes must be remapped into labels according to the relevant node’s label space.For an SRGB beginning at 10000, a global segment with index X is represented by label 10000+X.
  • SRGB mapping: Different SRGBs require the headend to account for downstream label mappings, and nodes may swap labels when forwarding toward later segments.The headend must know the SRGBs of nodes performing NEXT operations so subsequent labels are crafted correctly.
  • SRGB mapping: Using an identical SRGB in all routers avoids label remapping and ensures that a global segment has the same MPLS label throughout the SR domain.The survey notes that this recommended operating mode also avoids complications in operations and troubleshooting.

B. IPv6 data plane (SRv6)

SRv6 carries an ordered list of IPv6 SIDs in a Segment Routing Header and processes packets through source, transit, and segment-endpoint roles. Its network programming model associates functions with segments, extending SR beyond path steering.

  • SRH format: The SRv6 Segment Routing Header stores the SR Policy as an ordered list of IPv6 addresses, with Segments Left identifying the active SID.Each IPv6 address in the list acts as a Segment Identifier.
  • SRv6 operations: A Source SR node encapsulates a packet, inserts the SRH, stores the segment list in reverse order, and sets the first SID as the IPv6 destination address.The example uses S1, S2, and S3 with Segments Left set to 2 so S1 is active.
  • SRv6 operations: An SR Segment Endpoint decrements Segments Left, activates the next SID, updates the outer IPv6 destination address, and forwards the packet using IPv6 routing.These actions implement the NEXT operation at each segment endpoint.
  • SRv6 operations: Transit nodes forward SRv6 packets as ordinary IPv6 traffic, so IPv6 routers can serve as SRv6 transit nodes without SRv6 awareness.Transit forwarding implements CONTINUE between explicitly identified segments.
  • SRv6 operations: SRv6 can insert an SRH by encapsulation or directly between an IPv6 header and its next header for IPv6 packets.The direct insertion option is especially suited when the source host acts as the Source SR node.
  • Network programming: SRv6 Network Programming associates functions such as encapsulation, decapsulation, and routing-table lookup with segments.A 128-bit SID can be interpreted as LOCATOR:FUNCTION:ARGS, while a locator prefix provides reachability to a node hosting functions.

C. SRv6 Network Programming Model

SRv6 Network Programming combines functions associated with segments across multiple nodes to achieve objectives beyond packet routing. The model supports services including VPNs, traffic engineering, and fast rerouting, while control-plane designs range from distributed to centralized and hybrid.

  • Network Programming: SRv6 Network Programming combines functions in different nodes to implement networking objectives beyond packet routing.Functions are embedded in the packet header as a network program.
  • SRv6 Behaviors: SRv6 policies use headend behaviors to match packets and attach SID lists, while endpoint behaviors execute actions at SRv6 nodes.The paper distinguishes policy steering at source nodes from processing at endpoint nodes.
  • SRv6 Behaviors: SRv6 behaviors include encapsulation, insertion, destination updates, decapsulation, and forwarding through selected routing tables.Examples include H.Encaps, H.Insert, End, End.DT6, and End.DX6 behaviors.
  • Control Plane: Control planes may be distributed, centralized, or hybrid, with routers exchanging reachability information and controllers computing or enforcing SR policies.Hybrid deployment balances distributed connectivity with controller-based policy computation and configuration.
  • Control Plane: SR-MPLS distributes segment information through IGP extensions, whereas SRv6 uses IPv6 addresses as SIDs and avoids equivalent extensions for several segment types.SRv6 also does not require an SR-MPLS-style Segment Routing Global Block for these global segments.

E. Segment Routing motivations and use cases

Segment Routing emerged to address scalability limitations in MPLS traffic engineering and supports tunneling, fast reroute, traffic engineering, and diverse SRv6 deployment environments. Standardization and patent activity cover architecture, protocols, recovery, operations, measurements, and use cases.

  • Motivations: Segment Routing was motivated by MPLS-TE scalability problems caused by explicit state at every hop and limited exploitation of ECMP.SR was pursued as a more scalable alternative for traffic-engineered IP networks.
  • Use Cases: Identified SR use cases include MPLS tunneling for VPNs, Fast ReRoute, Traffic Engineering, and resiliency.SRv6 deployment environments include offices, access networks, data centers, content delivery networks, and core networks.
  • Standardization: The standardization survey classifies 14 RFCs and 50 Internet Drafts into seven categories.The classification covers architecture, use cases and requirements, FRR, OAM, performance measurement, and related activities.
  • Patents: The patent review covers 18 documents, including foundational SR principles, routing-protocol extensions, monitoring, coexistence with LDP, and applications such as WAN orchestration and network slicing.The surveyed patents span both SR-MPLS and SRv6 concepts and use cases.
  • Standardization: Key standards describe SR architecture, SR policies, network programming, service chaining, VPNs, mobile user-plane applicability, and fast reroute.TI-LFA precomputes backup paths for link, node, and local SRLG failures.

B. Relevant patents

The patent analysis finds SR-related intellectual property spanning foundational architectures, protocol extensions, monitoring, coexistence, orchestration, and emerging network applications. The research survey organizes SR work into categories and links those categories to specific SR topics.

  • Foundational Patents: Foundational patents cover label-based forwarding, SID lists, SR router behavior, IPv6 extension headers, and native SRv6 processing.These documents describe both MPLS-based and IPv6-based implementations of Segment Routing.
  • Protocol Extensions: Other patents extend routing protocols to signal SIDs, create SR policies through BGP, and advertise adjacency segment identifiers.These extensions transport SR-related configuration through existing control-plane mechanisms.
  • Applications: Patent applications address monitoring, LDP coexistence, fast reroute, loop avoidance, WAN orchestration, SID assignment, network slicing, mobile location reporting, and virtual-machine migration.The applications illustrate SR use across traffic engineering, SD-WAN, NFV, SDN, and service chaining.
  • Research Taxonomy: The research taxonomy groups works by categories such as Monitoring, Traffic Engineering, Failure Recovery, Centrally Controlled Architectures, Path Encoding, and Network Programming.A second classification relates these research categories to specific SR topics and features.
  • Research Results: Traffic Engineering and Centrally Controlled Architectures are the most investigated categories, while Network Programming has fewer works and source routing is the most used SR feature.The category-topic graph links monitoring and traffic engineering mainly to routing flexibility and source routing, and links path encoding to segment-list optimization.

A. Monitoring

SR-based monitoring research covers delay measurement, network health checking, traffic measurement, and traceroute. The surveyed approaches use source-routed paths, monitoring cycles, traffic perturbations, counters, and SRv6 eBPF functions, with distinct trade-offs in resource use and deployment requirements.

  • Monitoring Scope: Monitoring works use SR for delay measurements, network-device health checking, traffic-matrix estimation, and traceroute.The taxonomy associates delay measurement with source routing and health checking with routing flexibility.
  • Monitoring Optimization: Cycle-monitoring research proposes algorithms and ILP formulations that optimize cycle coverage, segment-list size, and longest-cycle length.The reported evaluation compares cycle-cover length, segment-list depth, and improvements against the SCMon baseline.
  • Delay Measurement: SR monitoring tools measure one-way end-to-end delay either with external timestamped probes or with Linux SRv6 eBPF functions.The eBPF-based approach does not require an external monitoring tool but is limited to Linux-based SRv6 routers.
  • Health Checking: Two health-checking approaches create cyclic SR paths; the newer cycle-based works optimize monitoring resources but do not support link bundles.SCMon supports parallel links and bundles at per-link granularity, whereas the cycle-based approaches do not.
  • Traffic Measurement: SR traffic-matrix tools either reroute flows to induce link-load changes or read dedicated SR traffic counters.Both approaches provide comparable traffic-matrix quality, but counter-based measurement does not affect network performance.

B. Traffic Engineering

The surveyed Traffic Engineering work uses Segment Routing’s path flexibility to optimize congestion, energy, rejected requests, and other network objectives, while addressing computational and operational constraints. Research spans theoretical complexity, scalable formulations, fast reaction to traffic changes, migration, and heuristic routing.

  • Traffic Engineering is a major SR research area, with 22 papers using SR for advanced routing solutions.The literature formulates TE as an optimization problem with an objective, parameters, and a network scenario.
  • General SR TE problems are NP-hard, while fixed-length shortest-path segment lists permit weakly polynomial-time minimization of maximum link utilization.When segment-list length is only upper-bounded, the problems become NP-hard again.
  • A three-segment forwarding model is proposed because two segments are insufficient to determine optimal paths and can waste bandwidth.
  • A hard-time-constraint heuristic reduces congestion with execution times below 1 second by quickly rerouting a subset of flows after traffic changes.The approach also seeks to keep the new routing strategy close to the current one and limit reconfiguration.
  • Other approaches reduce TE-solving overhead, support incremental SR migration, optimize link weights and load balancing, or shrink candidate segments with bounded stretch.The surveyed works include SR path variables, evolutionary algorithms, particle swarm optimization, and bounded-stretch constraints.

C. Failure Recovery

The surveyed Failure Recovery work covers link and node failures through rerouting, traffic duplication, centralized failover, and implementations in Linux-based SRv6 systems. Research includes mechanisms for multiple simultaneous failures, robust disjoint paths, bandwidth-aware restoration, and loop-free backup paths.

  • Nine research works address SR-based Failure Recovery and Network Resiliency for link or node failures.
  • TI-MFA extends TI-LFA to support multiple failures, whereas traditional TI-LFA can loop indefinitely under two link failures.TI-MFA is presented as a static fast-failover solution that does not require control-plane interaction.
  • SRv6 traffic duplication provides 1+1 protection over disjoint paths by sending data simultaneously over both active channels.The implementation uses mirroring behavior in the Linux kernel.
  • An automated compiler computes robustly disjoint paths that remain disjoint under specified failures, while also limiting segment count and addressing low-latency paths.The approach is described as proactive, fast, and self-healing without external intervention.
  • Other solutions optimize restoration bandwidth sharing, use interface-specific failover tables, or implement SRv6 TI-LFA with on-the-fly eBPF programs in Linux.
  • Only two surveyed works target multiple failures, while most other mechanisms use precomputed rerouting and two works use traffic duplication.

D. Centrally Controlled Architectures

Research on centrally controlled SR architectures spans distributed, centralized, and hybrid control designs, with implementations demonstrated across SR-MPLS, SRv6, SDN, PCE, and multi-layer networks. These works address scalability, path control, load balancing, resiliency, and service deployment through practical prototypes and evaluations.

  • Sixteen works investigate centrally controlled SR architectures, classified according to three aspects of their solutions.
  • SR supports network-service chaining and overlay resiliency by moving per-flow state into packet encapsulation and steering traffic around failures.
  • Simulated failure recovery recorded some packet loss and approximately 170ms recovery time, while centralized and preconfigured load-balancing designs trade controller generality for autonomous data-plane reaction.
  • SDN-based SR implementations move flow state into packet headers, reducing reliance on switch flow tables and optimizing flow-table and link-capacity usage.
  • Implementations combine logically centralized controllers with Linux SRv6 nodes, open APIs, legacy IP control planes, or extended DNS interactions with end hosts.
  • Multi-domain and multi-layer demonstrations use orchestrators, BGP-LS, PCEP, IS-IS, OpenFlow, or PCE mechanisms to compute and instantiate SR paths and services.
  • Demonstrated architectures include single-domain, multi-domain, SRv6 Linux, and SR-MPLS deployments, showing practical implementation across several control settings.

E. Path Encoding

Path encoding translates traffic-engineering paths into segment lists, balancing segment-list depth, forwarding-state requirements, path determinism, and hardware limits. The surveyed approaches use shortest-path reasoning, auxiliary graphs, optimization, and new SID mechanisms to address these constraints.

  • Eight papers study path encoding, which translates a network path into a sequence of SIDs called a Segment List.
  • Path-assignment methods compute short segment lists by examining subpaths and inserting node SIDs when unique-shortest-path conditions cease to hold.
  • Some algorithms minimize segment-list depth under ECMP or deterministic hop-by-hop constraints, but support for arbitrary paths depends on IGP link costs.
  • SR-LEAs compute successive shortest paths and replace labels while respecting a specified maximum segment-list depth and hardware limitations.
  • Creating new LSPs can shorten segment lists under max-SLD constraints but increases the forwarding rules required in routers.
  • Targeted SIDs replace one list entry with an associated SID sequence, reducing stack depth at the cost of additional node flow state and controller sessions.
  • Auxiliary-graph approaches encode paths using Dijkstra or Multi Commodity Flow formulations, while MILP can minimize overall Segment List length for a target TE path.

F. Network Programming

The surveyed network-programming work uses SRv6 functions to implement service chaining, operational network functions, load balancing, content delivery, and live migration. Implementations extend Linux, connect SR-aware and legacy functions, or shift service decisions into the data plane.

  • Only eight papers address network programming, covering Service Function Chaining and operational functions such as firewalls, load balancers, and zero-loss VM migration.
  • Linux SRv6 extensions support service-segment mapping and VNF connectivity, including architectures that host both SR-aware and SR-unaware VNFs.
  • SRv6Pipes chains stream-processing functions by enforcing end-to-end paths and using a transparent TCP proxy to expose bytestreams to network functions.
  • The SERA Firewall can operate in basic legacy-firewall mode or apply filtering conditions involving SR fields in advanced mode.
  • SRLB encodes randomly selected potential application servers in the first packet’s segment list, avoiding monitoring costs during application-aware server selection.
  • A CDN architecture combines chunk-level globally routable IPv6 addressing with in-network server selection and cache-admission prediction.
  • A live-migration design defines SR functions including conditional local processing to support zero packet loss in an SRv6-enabled data center.
  • SRNK supports legacy VNFs through SR-proxy behaviors but exhibits poor scalability as the number of VNFs within an NFV node increases.

G. Performance evaluation

Performance-evaluation research develops reusable SRv6 benchmarking frameworks, hardware offloads, and protocol coexistence implementations. The reported results include limited forwarding impact for service processing and similar latency between SRv6 translation and GTP-U encapsulation or decapsulation.

  • Four papers evaluate SRv6 implementations using frameworks, programmable hardware, or protocol-translation designs.
  • SRPerf benchmarks Linux and VPP SRv6 implementations for throughput and latency using No-Drop Rate and Partial Drop Rate metrics.
  • SRPerf automates testbed setup, SRv6 configuration, and experiment orchestration while supporting extensions to new implementations and benchmarking methods.
  • FPGA programmable cards partially offload SRv6 processing from VPP routers, aiming to improve data-path performance and free server CPU resources for VNFs or other workloads.
  • SRv6 translation coexists with GTP-U without a huge performance drop, and its behavior latency is similar to GTP-U encapsulation and decapsulation.

H. Miscellaneous

The miscellaneous works span alternative SR-like architectures, applications, and studies of routing metrics, multicast delivery, and IoT scalability. They also include pathlet-based interdomain services and SR-inspired IoT network programming.

  • Alternative architectures: CXP uses pathlets—partial paths advertised by domains—to stitch QoS-constrained services across network domains.Each ISP abstracts its network as pathlets connecting network edges.
  • Alternative architectures: Omnipresent Ethernet implements source routing with binary-routed labels embedded in Ethernet frames.Its proponents address SR scalability in multi-domain scenarios through packet-header size and table-state considerations.
  • Routing studies: Routing metrics influence shortest-path-based traffic engineering, with inverse capacity identified as a simple metric studied in the literature.The cited work studies metric influence rather than proposing a new heuristic.
  • Applications: SR-based multicast delivery targets efficient live video streaming for 5G users while reducing rule-update overhead and routing-table growth.The work mainly focuses on constructing an efficient multicast tree.
  • Applications: SR supports scalable and flexible forwarding for highly populated, mobile Industrial IoT scenarios by bypassing overloaded links and balancing load.A separate IoT model embeds programs and execution state in SRv6 segment lists for execution across IoT nodes.

Architecture.

The implementation section contrasts SRv6’s expanding Linux and VPP support with the more established SR-MPLS support. VPP provides SR policy and steering capabilities that Linux lacks, while both platforms expose extensibility for SR functions.

  • Implementation status: SR-MPLS is mature and vendor-supported, whereas the implementation discussion focuses mainly on the more actively developed SRv6 version.SR-MPLS can be incrementally deployed in existing IP-MPLS backbones through software updates.
  • Linux kernel: Linux added SRv6 headend behaviors in kernel 4.10 and endpoint behaviors in kernel 4.14 through Lightweight Tunnel support.The endpoint set includes End.X, End.T, End.DX2, End.DX4, End.DX6, End.DT6, End.B6, and End.B6.Encaps.
  • Linux kernel: Kernel 4.18 extended SRv6 matching in netfilter and enabled custom SRv6 network functions implemented as eBPF programs.The matching extensions cover the SRH Previous SID, Next SID, and Last SID.
  • Linux kernel: Linux SR-MPLS support evolved through MPLS forwarding, LWT, tunnel, and multipath features, with multipath added in kernel 4.5.The MPLS LSR behavior appeared in kernel 4.1, followed by further extensions in kernel 4.3.
  • Policy framework: Linux lacks the SR policy framework, including BindingSID association and SR steering-rule instantiation, that is available in VPP.VPP supports SRv6 headend and endpoint behaviors, multiple SID lists, weighted load balancing, and precomputed rewrite strings.
  • VPP: VPP steers traffic into SR policies through BindingSIDs or steering policies, using a hierarchical FIB structure.Its SRv6 LocalSID framework lets developers add endpoint behaviors as VPP plugins, while SR-MPLS supports steering and spray policies.

C. Other open source implementations

Open-source SR implementations cover Linux extensions, routing stacks, SDN controllers, VPP-based systems, service programming, and experimental interoperability. Reported deployments and hardware support show SRv6 activity across vendors and operator networks.

  • Linux-based implementations: SREXT complements Linux SRv6 support with additional processing capabilities and patched user-space tooling.It was developed when the Linux kernel provided only basic End behavior.
  • Routing stacks: FRRouting experimentally supports OSPFv2 extensions for SR-MPLS but does not support SRv6 in the reported version.The support is tied to the cited draft on OSPFv2 Segment Routing extensions.
  • SDN implementations: SPRING-OPEN and PMSR implement SR-MPLS with logically centralized SDN control planes using ONOS or OpenFlow-based components.Trellis later incorporated parts of SPRING-OPEN and added P4/P4Runtime and Stratum support.
  • SDN implementations: SRN combines a centralized controller with DNS-based end-host interaction and OVSDB-based communication with network nodes.The nodes populate distributed topology and traffic-engineering metadata used by the controller.
  • SRv6 extensions: Other implementations provide centralized SRv6 control, stream-oriented in-network function chaining, and additional SRv6 service behaviors.SRv6 policies can be installed through SRN or directly on edge nodes with iproute; SRNK adds End.AS and End.AD.
  • Deployment and evaluation: Published implementations include reproducible robust-path experiments, interoperability tests, production hardware support, and eight listed nationwide SRv6 deployments.The deployments include Softbank, China Telecom, Iliad, LINE Corporation, China Unicom, CERNET2, MTN Uganda, and NOIA Network.
  • Tooling and acceleration: Open-source tools including Wireshark, tcpdump, iptables, nftables, and Snort support processing or inspection of the IPv6 Segment Routing header.An additional implementation offloads SRH operations and SRv6 cache handling to Intel FPGA programmable cards integrated with VPP.

VI. LESSONS LEARNED

The survey presents SR as a scalable and incrementally deployable architecture, with SRv6 emerging as the main direction for network programming and future research. Its review also identifies gaps in failure monitoring, multi-segment traffic engineering, and control-plane evaluation.

  • General outcomes: SR reduces flow state in network nodes and confines packet classification to border nodes, leaving transit nodes without per-flow state.The paper presents these properties as scalability benefits over earlier source-routing deployment concerns.
  • Deployment: SR-MPLS avoids changes to the MPLS forwarding plane, while SRv6 can transition from classical IPv6 in successive steps without service disruption.The paper characterizes both as incremental deployment paths for service providers.
  • Network programming: SRv6 network programming supports NFV and SFC by combining basic functions into packet-embedded network programs, potentially simplifying architectures relative to SR-MPLS.The paper states that implementing the same model on an MPLS dataplane would not be scalable.
  • Standardization and patents: The survey reports a standardization trend in which patents are later standardized or incorporated into activities led by the same vendors.Recent patents also concern network slicing, 5G, and cloud-based networking.
  • Monitoring: Monitoring research improves existing tools and develops SR-specific tools, but relatively few works address failures such as misconfigurations, undefined SIDs, black holes, or packet loss.The review identifies failure monitoring as an underrepresented topic.
  • Traffic Engineering: Multiple segment lists per flow are rarely exploited in traffic engineering, although single lists already provide substantial routing flexibility.The survey suggests multiple lists as a future avenue for further improving traffic-engineering solutions.
  • Centrally Controlled Architectures: Research on SR-MPLS favors centralized control, partly because routing-protocol extensions encouraged use of SDN, whereas SRv6 does not strictly require those extensions.Distributed control remains supported for SR-MPLS.
  • Path Encoding: Path-encoding research treats packet-header overhead as a deployment constraint and pursues either better path-to-list translation or smarter segment-list encoding.Adjacency SIDs are common in path-encoding work but less exploited in traffic engineering because they increase optimization complexity.

A. Service Function Chaining support

SRv6 programmability supports Service Function Chaining and Network Function Virtualization, while ongoing work targets deployments across hosts, cloud orchestrators, applications, and 5G networks.

  • Service Function Chaining and Network Function Virtualization: SRv6 programmability enables Network Function Virtualization and Service Function Chaining in provider networks.The paper identifies dedicated SRv6 control procedures for managing network functions as a research opportunity.
  • End-Host Implementation: SRv6 implementation research includes moving packet processing toward SmartNICs and using Linux eBPF and XDP for end-host functions.These directions target SRv6 processing closer to hardware or within fast kernel networking paths.
  • Cloud and Datacenter Integration: SRv6 can replace legacy datacenter tunneling mechanisms such as VXLAN by integrating needed information into SIDs or TLVs.This approach could simplify the datacenter network stack without dedicated tunneling headers.
  • Application Integration: Applications could use SRv6 SIDs to express service requirements and participate dynamically in composing network services.The paper notes that operating-system APIs must first be extended and SRv6-aware applications developed.
  • 5G Networks: SRv6 is being considered for future 5G data planes because of its stateless traffic steering and programmability features.Performance evaluation remains important for verifying whether strict 5G latency constraints are met.
Loading 1904.03471v5…