Abdullah 2018

This article has been accepted for publication in a future issue of this journal, but has not been
fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/COMST.2018.2869754, IEEE
Communications Surveys & Tutorials
Segment Routing in Software Defined

Networks: A Survey
Zahraa N. Abdullah∗ , Imtiaz Ahmad† and Iftekhar Hussain‡
Department of Computer Engineering∗ † , Kuwait University, State of Kuwait

Infinera Corporation‡ , 169 W Java Dr, Sunnyvale, CA, USA Email:
∗
znaabdullah@gmail.com, † imtiaz.ahmad@ku.edu.kw,‡ ihussain@infinera.com
Abstract
Segment Routing (SR) has emerged as a promising source-routing methodology to overcome the
challenges in the current routing schemes. It has received noticeable attention both in industry and
academia, due to its flexibility, scalability, and applicability, especially in Software Defined Networks
(SDN). The emerging cloud services require strict Service Level Agreements (SLAs) such as packet loss,
delay, and jitter. Studies have shown that traditional network architectures lack the essential flexibility
and scalability to offer these services. To combat this, a more flexible and agile routing paradigm of
SR enables a source node to steer an incoming packet along a performance engineered path represented
as an ordered list of instructions called segment list. This is encoded as a MPLS label stack or an
IPv6 address list in the packet header. This article provides a comprehensive review of the novel SR
technology by describing its architecture, operations, and key applications to date. SR paradigm can be
effectively applied to a wide range of network applications, such as Traffic Engineering (TE), network
resiliency, network monitoring, and Service Function Chaining (SFC), to achieve efficient network
solutions. Furthermore, this paper identifies an interesting set of future research directions and open
issues that can help realize the full potential of the emergent SR paradigm.
Keywords: Segment Routing (SR), Software Defined Networks (SDN), Controller, Control Plane,
Data Plane, Traffic Engineering (TE), Network Monitoring
I. I NTRODUCTION
Traditional network architectures are unsuitable to meet the cloud-based services requirements
of modern data centers and carriers. These limitations arise due to network infrastructure inflex-
ibility (e.g., tight coupling between control and data planes leading to a specific vendor lock-in)
1553-877X (c) 2018 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/COMST.2018.2869754, IEEE
and lack of automation and programmability contributing to poor network operational efficiency
and scalability. The large scale data centers typically contain tens of thousands of network
devices (routers or switches) arranged in a hierarchical CLOS based topology with hundreds
of thousands of links and millions of routing rules [1]. The configuration and management
of such a large scale network using error-prone repetitive manual configuration tasks pose
serious operational challenges. Automation and programmability capabilities in the network
infrastructure are required to enable end-to-end management. A network device needs to not
only furnish a wide range of automation capabilities but also must provide robust programmatic
interfaces to allow applications to provision network resources (e.g., bandwidth) to meet Service
Level Agreements (SLAs) and monitor network performance.
The promising Software Defined Networking (SDN) technology is radically transforming the
network architecture of data centers, network overlays, and carrier networks to overcome most of
the aforementioned limitations of the traditional network architectures [2]–[4]. SDN decouples
control and data planes, logically centralizes network intelligence and state in the controller, and
abstracts the network infrastructure layer from the applications through well-defined northbound
and southbound Application Programming Interfaces (APIs) [2]–[8]. For instance, applications
may gather network intelligence information from the controller using web-based Representa-
tional State Transfer (REST) APIs, run its algorithms, and orchestrate new rules throughout the
network. The control layer communicates with the data plane through the southbound APIs.
The SDN controller can dynamically make changes to the data plane in network devices (e.g.,
add or remove a forwarding entry in the forwarding table) through the southbound APIs. On
the southbound APIs, multiple protocols can be supported such as OpenFlow [2], Network
Configuration Protocol (NETCONF) [9], Border Gateway Protocol Link State (BGP-LS) [10],
and Path Computation Element Communication Protocol (PCEP) [11]. Controller discovers the
topology of the network dynamically by peering via Interior Gateway Protocols (IGPs) (e.g.,
ISIS-TE, OSPF-TE) or listening to BGP-LS updates. The controller can learn about the path
state, modify existing paths, or provision new paths using PCEP. In short, SDN enables a
number of benefits including decoupling of control and data planes, programmability, simple
programmable network devices, greater freedom for external software to define behavior of a
network which encourages innovation, reduction in capital expenditure through improvement in
network efficiency, and reduction in operational expenses through ease of configuration [4]. The
SDN architecture ability to view network state in real-time, and programmability of network
devices are ideally suited for developing innovative security capabilities that can be instantiated
on-the-fly.
Cloud services providers such as Microsoft and Google are increasingly deploying SDN based
architectures to improve their inter-data center networks efficiency. For example, the SWAN
(Software-driven WAN) research from Microsoft showed that inter-data center WANs suffer
from poor link utilization in the 40-60% range [12]. This study identified the distributed resource
allocation of MPLS-TE (Multiprotocol Label Switching Traffic Engineering) as the key reason
behind the poor network efficiency. In a traditional traffic engineering with distributed control
plane model, since there is no entity with a global view of the network, ingress routers greedily
select paths for their traffic that can result in globally sub-optimal routing patterns. To achieve
higher network utilization, the SWAN paper proposed a centralized MPLS-TE control plane
architecture to allocate network paths and use OpenFlow to re-configure the network’s data
plane to match current traffic demands. The research in [13], reported the largest OpenFlow
driven SDN deployment for B4, a private WAN connecting Google’s data centers across the
globe. The proposed architecture consists of a logically centralized traffic engineering control
plane (e.g., OSPF, ISIS, and BGP for distributing topology) and OpenFlow to program switches
built from merchant silicon for the B4. The study demonstrated the ability of the proposed SDN
architecture to drive B4 WAN links to near 100% utilization. While B4 SDN deployment showed
promising results, this approach does not generalize to all WANs. The B4 SDN deployment study
also acknowledged a number of OpenFlow related scalability issues (such as frequency of flow
setups and gathering flow statistics) that would require further work to meet the demands of
high performance WANs.
While OpenFlow-driven SDN centralized control plane architecture and OpenFlow high degree
of per flow granularity has helped to improve the overall network efficiency, several challenges
remain. First, this architecture requires multiple interactions between the SDN controller and
network devices along the traffic path. To set up a path for a flow, the SDN controller needs to
program all devices along the path. This can lead to poor scaling (e.g., in terms of the amount of
state required) as the number of flows and network size grow. Second, every time traffic demand
or network topology changes, the controller is required to update the network’s data plane in
order to maintain high utilization. In this situation, a key challenge for the controller is to be
able to make updates across multiple switches rapidly to reduce network convergence time and
minimize any transient congestion and the packet loss resulting from inconsistent forwarding
state in the network. The total amount of time to make a Forwarding Information Base (FIB)
update includes transmission and propagation delays - to distribute FIB entries to a switch -
and the additional delay incurred to install the FIB entries on the switch hardware (e.g., Ternary
Content-Addressable Memory (TCAM)). This can lead to increased network convergence time
for FIB updates depending on the FIB size and the number of switches involved in the path.
While the aggressive use of wild-carded rules and effective flow management ways proposed
in [14], [15] may help in reducing the TCAM entries and controller-switch interactions, as
demonstrated by the Google B4 SDN study, this still does not obviate the requirements to
maintain per flow state in the network and program switches along the flow path. That said, it is
worth noting that recently Open Networking Foundation (ONF) have started an initiative called
SPRING-OPEN. The objective of this project is to prototype an Open Segment Router (OSR)
with an initial set of capabilities to route unicast IPv4 packets using the MPLS data plane [16].
In the ONF SDN approach, OpenFlow version 1.3+ is used to program segments list, instead
of using routing protocols such as OSPF/ISIS for distributing topology and segment identifiers
(SIDs), the controller is used for discovering and maintaining the topology information. However,
it is important to note that the SPRING-OPEN project does not aim to create a Generally
Available (GA) product nor it will be ready to for WAN scale SDN use cases.
The emerging cloud services require strict SLAs such as packet loss, delay, and jitter. This has
led Internet Engineering Task Force (IETF) standardizing a flexible architecture called Segment
Routing (SR) [17]–[32]. While SDN and SR technologies can be deployed independently, when
used together they enable much more powerful solutions. It is possible to satisfy use case such as
sub-second protection switching at the IP layer by deploying SR purely based on the distributed
control plane (without SDN centralized control). However, combining SDN centralized control
with the SR enables a much broader set of use cases and allows network operators to reap
maximum benefits from the SR source routing paradigm. To be more specific, a centralized
SDN controller allows to collect and monitor topology changes with a global view of the
network across, compute traffic engineering paths using standard PCE framework, and use
standard protocols such as PCEP on the SBI to program an ingress node with the new path
information to adapt to the network topology changes quickly. In brief, the combination of SDN
and SR technologies enables following key benefits including vendor neutrality (e.g., SR control
protocols are based on IETF open standards), programmability (e.g., SBI protocols are based on
open standards such as IETF and ONF, programming of interoperable overlays and underlays
[33]), scalability (e.g., use SR source routing to minimize state and state changes by maintaining
state at the source node only), agility (e.g., increase responsiveness to topology changes by having
to program the source node only, inherit proven convergence and resiliency characteristics of
standard routing protocols), and centralized manageability (e.g., efficient management of network
valuable resources based on a global view of the network topology across one or more domains,
ability to route traffic along an explicit path with or without ECMP-awareness). These key
characteristics of the combined SDN and SR network architecture have led to adoption of the
SR approach into designs of some of the open source SDN controllers such as OpenDaylight
using the PCEP for controlling SR tunnels [8].
SR is a source routing based paradigm which allows a source node (i.e., network device)
to specify a path as an ordered list of segments to guide a packet across the network [18]. A
segment is an instruction a node executes on the incoming packet. A segment scope can be local
to a SR device or global within an SR domain (see Section II). In SR, the header has sufficient
information to steer the packets from the ingress node to the egress node of the path. As a
result, there is no need for any additional signaling protocol which simplifies the control plane.
Furthermore, this also improves network scalability as the intermediate nodes along the path do
not need to maintain state for all steered paths through the network. The set of nodes participating
into the source based routing model defines an SR domain. SR is a general paradigm that can
be applied to a packet forwarding technology with the source routing capability such as MPLS
and IPv6.
SR can be realized over MPLS data plane without any change. In the SR instantiation using
MPLS, a segment is encoded as an MPLS label and an ordered list of segments is encoded as a
stack of labels [19]. The label on the top of the stack indicates the active segment. An ingress
network device enforces a desired path for a set of packets by adding the segment list on the
packets. The receiving network device processes the top label in the segment list (i.e., the active
segment) to forward the packet to the next hop according to the given instruction (e.g., forward
packet to shortest path to destination or forward packet through a specific interface or deliver a
packet to a given service). Upon execution of the active segment, the associated label is popped
(i.e., removed), and the following label (i.e., the next label underneath the popped label) becomes
the active segment. Segment Routing can also be realized over IPv6 data plane using a new type
of routing extension header called Segment Routing Header (SRH) [20]. In this case, a segment
is encoded as an IPv6 address and an ordered list of segments is encoded as an ordered list of
IPv6 addresses in the routing header. The Destination Address of the packet indicates the active
segment. Upon completion of a segment, a pointer in the SRH is incremented and indicates the
next active segment. The SRv6 network programming allows a set of endpoint functions that
can be associated with local segments [33].
An SR path can be derived from a variety of mechanisms including an IGP Shortest Path
First (SPF) algorithm, a Constrained Shortest Path First (CSFP) algorithm which may take into
consideration constraints such as bandwidth, latency, and Shared Risk Link Group (SRLG), or
an explicit network operator’s configuration. An SR path derived from the SPF algorithm is
called an SR-SPF path, which allows a packet to be forwarded along the well-known IGP Equal
Cost Multi Path (ECMP)-aware shortest path. An SR path derived from the CSPF algorithm
or an explicit configuration is called an SR Traffic Engineered (SR-TE) path. An SR-TE path
allows a packet to be steered along an explicit path that may deviate from the IGP SPF path. In
general, SR-TE paths are supported by using a combination of local and global segments. These
capabilities allow an SR architecture to support many use cases including tunneling of layer 2
and layer 3 Virtual Private Network (VPN) services from an ingress node to an egress node
using SR-SPF paths, traffic engineering using SR-TE paths, network resiliency by rerouting the
traffic from a failed path over new paths from the protecting node to the destination, Operations,
Administration and Maintenance (OAM) for monitoring the state of the network, and Service
Function Chaining (SFC) in the Network Function Virtualization (NFV) environment by steering
a packet through a sequence of service functions (such as Firewall, Deep Packet Inspection (DPI))
using a service segments list. A service segment identifies a service (or service function) provided
by a node processing the packet such as firewall and DPI.
The flexibility, scalability, and ability to support a wide range of use cases has positioned the
SR architecture as an attractive solution for fulfilling the evolving requirements of carrier-grade
networks towards cloud-based services. A cloud service is any service that is made available
to users on demand via the Internet from a cloud service provider servers in data centers. SR
is already supported by system vendors (e.g., Cisco, Juniper) and under evaluation by network
operators. Google Inc. for instance, has applied SR concept to fulfill its OAM requirements
by using the SR technology in a central approach. This approach was based on triggering the
OAM from a monitoring server where all the pre-calculated paths are validated. This centralized
OAM monitoring is implemented to monitor the state of resources in the network, which is a
fundamental requirement, with least overhead where it outperforms the traditional tools [34],
[35]. Additionally, SR concept is gaining popularity in the industries, as the service provider
networks are increasingly adopting SR in conjunction with SDN. The work conducted in [36] has
facilitated the paths updates in a large scale highly dynamic SDN network. Their methodology,
Fast and Lightweight Updates (FLUS), exploits the SR approach to construct the new desired
path by concatenating the old segment list with the newly calculated ones to express the new
path towards the destination.
The work done in [37] proposed an SDN framework that is implemented using an SR supported
Carrier Ethernet as Software Defined-Carrier Ethernet Switch Routers (SD-CESRs). Carrier
Ethernet is a properly standardized solution that is considered as a service-oriented modified
version of Ethernet. Their work was deployed for field trials in a tier-1 service provider network,
and it has demonstrated a good performance in terms of network agility (i.e., automated service
provisioning and service lifetime management) [37]. The authors in [38] have also proposed an
evolved carrier Ethernet network architecture that combines the strengths of SR based transport,
L2VPN service with BGP Ethernet VPN (EVPN) control plane [39], and SDN for service
provisioning to build an architecture capable of delivering end-to-end Ethernet services (Res-
idential, Business, Mobile Backhaul) with simplicity, programmability, and guaranteed service
level agreements over a programmable network infrastructure. Another generic work has been
proposed in [40] where SR enabled transport paradigm is implemented specifically in IP/MPLS
Carrier Ethernet technology. This work fully leverages the SR benefits in IP/MPLS networks by
introducing several different techniques for swap node selection that showed an increased results
of network scalability.
Several additional experimental demonstrations of SR were introduced in [41], where the
results have proven a performance enhancement. The demonstration was based on implementing
the SR concept in two different test beds, SDN and PCE. The first implementation scenario
uses OpenFlow nodes and switches with SDN-based SR controller. The second scenario is
implemented using IP/MPLS commercial routers and an extended version of PCE solution as the
SR controller. Both implementation scenarios have shown a successful dynamic traffic rerouting
with no packet loss while eliminating the need for complex signaling protocols.
Despite the attention and wide industrial acceptance the SR paradigm has received, no survey
papers were done in the literature that signify the need for researchers to do more work in
SR field. This timely survey highlights Segment Routing core set of features and key use
cases in the SDN context. The rest of the paper is organized as follows: In Section II, an
overview of SR Architecture is provided. Section III describes use cases to better understand their
application. Section IV discusses the SR architecture implementation related aspects including
the construction and encoding of the segment list that are demonstrated through numerous use
cases. In addition, the application of SR in networks, especially in SDN enabled networks, is
provided in Section V. Section VI addresses some open issues in the SR, which can be rich areas
for future work. Finally, the paper concludes in Section VII. A description for the acronyms used
in the paper is provided in Table I.
II. SR A RCHITECTURE
In order to understand how SR works and how it can be applied to various use cases, some
architectural components and concepts must be introduced. SR utilizes the notion of a segment list
to steer a packet along an explicit path. A segment is an instruction an SR capable node executes
on an incoming packet. A segment can represent a topological or service related instruction. For
instance, a segment may instruct a node to forward a packet using a shortest path to destination,
forward a packet through a specific interface (i.e., a topological instruction), or deliver the packet
to a given service instance to get a specific treatment such as DPI and firewalling (i.e., service
related instruction). A segment can have a scope that is local to an SR node or global within an
SR domain. A segment whose scope is local to an SR node is called a local segment. A segment
whose scope is global within an SR domain is known as a global segment. A local segment that
identifies a particular service (or service function) at a node is known as a service segment. The
set of nodes participating into the source based routing model defines an SR domain. The SR
architecture has two main components, namely, the data plane and the control plane. In the data
plane, we describe segment ID (SID) and, then, different types of IGP segment types with their
use cases followed by the control plane functions.
1) Data Plane: The SR data plane component is concerned with defining procedure for
encoding a sequence of segments (instructions) on a packet and processing the segments
list for forwarding the packet. The header contains the segment list along with a pointer
that indicates the active segment to be processed by the current holding device, where
this pointer points to the next segment when the current one is executed [17], [18]. Each
segment in the list is identified with a segment ID (SID) that may be of global or local
significance. The global segment ID is advertised to all the existing nodes in the network
AS Autonomous System
BCCP Bounded Cycle-Cover Problem
BGP Border Gateway Protocol
BSID Binding Segment Identifier
CR Core Router
CSPF Constrained-Shortest Path First
DPI Deep Packet Inspection
E2E End-to-End
ECMP Equal Cost Multi Path
FIB Forwarding Information Base
FLUS Fast and Lightweight Updates
ICT Information and Communication Technologies
IETF Internet Engineering Task Force
IGP Internet Gateway Protocol
ILP Integer Linear Programming
IoT Internet of Things
ISIS Intermediate System-to-Intermediate System
LDP Label Distribution Protocol
MPLS Multiprotocol Label Switching
MSD Maximum SID Depth
NBI NorthBound Interface
NFV Network Function Virtualization
OAM Operations, Administration and Maintenance
OSPF Open Shortest Path First
PCE Path Computation Element
PE Provider Edge
RSVP-TE Resource ReSerVation Protocol -Traffic Engineering
SDN Software Defined Networks
SD-CESRs Software Defined-Carrier Ethernet Switch Routers
SFC Service Function Chaining
SID Segment Identifier
SLA Service Level Agreements
SLD Segment List Depth
SPH Segment Packet Header
SPRING Source Packet Routing in Networking Group
SR-LEA-A SR Label Encoding Algorithm With Global Adj-SID
SR-LEA SR Label Encoding Algorithm
SR Segment Routing
SRGB Segment Routing Global Block
SRLG Shared Risk Link Group
TCAM Ternary Content Addressable Memory
TE Traffic Engineering
TABLE I: List of acronyms
10
and thus must be unique within its domain. In MPLS instantiation of the SR, each SR
node maintains a set of local labels reserved for global segments in the SR Global Block
(SRGB). Global segments are advertised as a label range and an index. For example, if an
originating node advertises a label range [100, 199] and an index= 1, the receiving node
determines the global segment’s label value to be 101 (i.e., SRGB=[100,199], index range
= 0 to 199, index=0 means label=100, index=1 means label=101, and so forth). While the
SR architecture allows different SRGB ranges in each node, it is highly recommended to
configure the same SRGB on all nodes within the SR domain to simplify operations and
troubleshooting (as illustrated in Figure 1).
On the other hand, a local segment is held only by the originating node and its value is
assigned outside the SRGB range (i.e., a locally allocated label). In SR with IPv6 data
plane, unlike the MPLS, as there are no restrictions on which IPv6 address can be used,
the notion of the SRGB includes all IPv6 global address used within the SR domain.
The SR architecture defines several data plane operations including PUSH (instruction
to insert a segment at the top of the segment list), NEXT (when the active segment is
completed, NEXT instruction allows to inspect the next segment), and CONTINUE (when
the active segment is not completed and CONTINUE instruction allows to keep the active
segment unchanged). Figure 2 illustrates SR segmentation operations and equivalent MPLS
label operations. In SR with the MPLS data plane, several types of segments are defined
including an IGP segment, a BGP peer segment, an LDP segment, an RSPV-TE LSP
segment, and a BGP LSP segment [17]–[20]. An IGP segment or IGP SID is a generic
term for a segment which represents a piece of information that an SR-capable IGP node
advertises such as attached prefixes and adjacencies. The SR architecture can be applied
not only to IGP segments, but also to other forms of segments (e.g., segments signaled
through LDP, RSVP-TE, and BGP). For the sake of brevity only IGP segments are covered
in this study. The IGP segments play a key role in the SR paradigm and its various use
cases. This is because IGP segments allow to express an arbitrary SR path across the IGP
domain using a single IGP segment or a list of multiple IGP segments. Figure 3 provides
a summary of IGP segments types defined in the SR architecture and a brief description
of each IGP segment type follows.
a) IGP Adjacency Segment: An IGP segment attached to a unidirectional adjacency or
11
Fig. 1: Illustration of the same SRGB allocation on all SR nodes
set of unidirectional adjacencies is referred to as an Adjacency Segment [18]. An IGP

adjacency is established by the local node and the remote node. An adjacency segment
is local to the advertising node (unless explicitly advertised as a global segment). The
SID of an IGP adjacency segment is called an Adj-SID. The adjacency segment (or
adjacency SID) refers to a given link (or set of links) that lies between two adjacent
nodes; it provides the feature to steer the traffic through a specific interface. Adjacency
segments, when used along with the prefix or node segments enable an ECMP-aware
explicit path. Suppose the node R4 allocates an Adj-SID of 24002 to the adjacency
toward R5 and advertises the Adj-SID in the IGP. If R1 wishes to forward a packet
via the R4 to R5 link, it pushes segments list including the Adj-SID 24002 on the
packet (the segments used to forward the packet from R1 to R4 are not shown).
When R4 receives a packet with the label 24002 as the active segment, it pops the
label, and due to the Adj-SID 24002’s instruction forwards the packet on the link
toward R5 as depicted in Figure 4.
b) IGP Prefix Segment: An IGP-Prefix Segment represents a global prefix (unless adver-
tised otherwise) with the SR IGP topology and denotes an instruction to forward the
packet along the path computed using the specified routing algorithm (e.g., ECMP-
aware shortest-path to the prefix). The SID of the IGP Prefix Segment is referred
12
Fig. 2: Illustration of segment operations
Fig. 3: IGP segment types
to as the Prefix SID. An illustration of an IGP prefix segment is given in Figure

5. Assume operator allocates an IP prefix of 192.0.1.6 on R6, configures the same
SRGB [1000-2000] on all nodes, and assigns an IGP SID 1006 to 192.0.1.6/32. The
SR control plane advertises the IGP SID 1006 within the IGP domain. R1 sends
a packet to a prefix 192.0.1.6/32 attached to R6 by pushing the segment list 1006
13
Fig. 4: Illustration of an IGP Adjacency Segment
on the packet header. Since the IGP prefix has a global semantic within the IGP
domain, any router forwards the received packet with the active segment of 1006 to
the next-hop along the ECMP-aware shortest-path to the prefix 192.0.1.6/32.
c) IGP-Node Segment: This is an IGP Prefix Segment which identifies a specific node
(e.g., a loopback interface). This is also called an IGP Node Segment. The SID of the
IGP Node is called the Node SID. An IGP Node SID must be owned and allocated
by a single node within a given IGP domain. The semantic that is associated with this
type of SID is same as for the IGP Prefix segment i.e., forward the packet towards the
node with this ID through the shortest possible ECMP-aware path. Let 1006 denotes
the node SID of R6, where R1 pushes that Node SID into the packet header. The
packet is steered towards that Node SID (i.e., R6) using the shortest ECMP-aware
possible path which is either R1-R2-R4-R6 or R1-R3-R5-R6. Figure 5 shows how
Node-SID is used to steer the packet from the ingress node R1 to the egress node
R6. This assumes R6 (the originator of the Node SID 192.0.1.6) has instructed R4
and R6 to not remove the active segment (e.g., by advertising no penultimate hop
option for the Node SID in the control plane). IGP Prefix/Node segments may also
be combined with the IGP Adjacency Segments to steer traffic along an explicit path
14
Fig. 5: Illustration of IGP Prefix/Node Segments
through the network as illustrated in Figure 6. In this case, R1 sends a packet to R6

by pushing an SR header with segment list 1004, 24002, 1006. Since 1004 is a global
IGP segment attached to the IP prefix 192.0.1.4/32 when R2 receives a packet with
the active segment 1004 based on the FIB entry it pops the 1004 (exposing 24002
as the next active segment) and forwards the packet along the shortest-path to the
next hop (R4). When R4 receives the packet with the active segment 24002 it pops
the label and forwards the packet over R4-R5 link. When R5 receives the packet it
forwards it along the shortest-path to R6.
d) IGP Anycast Segment: An IGP Anycast Segment is an IGP Prefix Segment which
identifies an anycast prefix advertised by a set of routers. The SID of the IGP Anycast
Segment is referred to as the Anycast-SID. An IGP Anycast Segment allows to
enforce the ECMP-aware shortest-path forwarding towards the closest node of the
anycast set. All nodes in the Anycast set must advertise the same prefix with the same
SID value. An IGP-Anycast segment must not reference a particular node. Figure 7
illustrates forwarding behavior for an IGP Anycast Segment where an Anycast SID
1003 is assigned for the IGP anycast prefix 192.0.1.3/32 configured on both R3 and
R4 (i.e., R3 and R4 are member of the same anycast set). Suppose R2 receives a
packet destined to Anycast-SID 1003. Since prefix 192.0.1.3 is reachable from R2
15
Fig. 6: Illustration of combining Prefix-SIDs and Adj-SIDs for an explicit path
via R3 and R4, R2 load-balances traffic to anycast SID 1003 over both ECMP paths.
If R3 fails, R2 automatically forwards traffic to Anycast SID 1003 towards R4 as
depicted in Figure 8. In summary, IGP Anycast segments enable High Availability
(HA), ECMP, and traffic engineering using macro TE expressions (i.e., coarse TE
policies).
e) Service Segment: A Service Segment is a local segment that can be used to represent
a particular service treatment to be applied to a packet. By combining IGP segments
with the service segments (represented as Service-SIDs), SR can be used to steer
packets through services offered by middleboxes to perform specific actions such as
firewalling and DPI. An example use case of service segments is illustrated in service
chaining application (see Section V).
2) SR IGP Control Plane: A link-state IGP domain contains protocols such as OSPF and ISIS
for exchanging routing information between routers. An SR capable node needs to advertise
segment identifiers for its associated IGP prefixes and adjacencies within the IGP domain.
The link state IGP control plane is responsible of advertising the IGP segment identifiers
among the network devices. IGP control plane (OSPF, ISIS) extensions are required to
16
Fig. 7: Illustration of an IGP Anycast Segment
Fig. 8: Illustration of IGP Anycast Segment providing High Availability
17
advertise the various IGP SIDs. These IGP extensions allow any router in the IGP domain
to maintain a database of all IGP segments within the domain and update the database
rapidly upon network topology changes [21]–[23]. Moreover, the SR IGP control plane
guides the ingress router in selecting the SR path that a packet should follow [21]–[23].
When one or more IGP-Node Segments (i.e., loopback IP addresses) are configured on an
SR node, for each configured IGP prefix the SR node advertises the assigned IGP SID.
When such an IGP prefix is removed, the SR node withdraws the associated IGP SID.
The SR node advertises an Adj-SID for each adjacency on a point-to-point link that is in
neighbor state 2-Way or higher. When an adjacency on a point-to-point link transitions
to a state lower then 2-Way, then the node withdraws the associated Adj-SID for that
adjacency.
Apart from the IGP segments, SR contains other type of segments which are referred to
as BGP segments and BGP peering segments. BGP segments are LDP LSP, RSVP-TE
and BGP LSP. BGP segments allow the traffic to use any path that is different from the
calculated shortest path. The BGP peering segments are used to steer traffic from one
Autonomous System (AS) to another, which makes it an attractive tool in the inter-domain
multipoint transmission scenarios. For instance, an ingress border router of an AS may
construct a list of segments to steer a flow along an explicit path within the AS, towards a
selected egress border router of the AS and through a specific peer. In the simplest form,
the ingress border router may compose the segment list by using an IGP Node SID of the
selected egress PE and a BGP peering segment (e.g., BGP Peer Node segment or BGP
Peer Adjacency segment) for the selected egress BGP peer or peering interface. However,
BGP segments and the associated SR control plane extensions are out of the scope of this
study [18] [42], [43]. It is worth mentioning that SR can be easily applied in both IPv6
and MPLS networks. In MPLS, minimal or no hardware changes are required in the data
plane to cope with SR. In IPv6, SR is a fully compatible solution that can be used with
ECMP to perform load balancing, and the full implementation is addressed with details
in [44]. Also, a Linux Kernel implementation of SR over IPv6 networks is introduced in
[45], however, SR over IPv6 data plane is out of the scope of this paper.
III. IGP S EGMENTS SR U SE C ASES
This section describes SR use cases enabled by the IGP segments.
18
Fig. 9: SR based simplified transport for MPLS VPN services
A. Simple Transport Paths for L2VPN and L3VPN Services
Service providers commonly employ MPLS data plane to provide Layer 2 Virtual Private
Network (L2VPN) and Layer 3 Virtual Private Network (L3VPN) services over a common
network infrastructure. An important task of enabling these services involves establishing a full
mesh of MPLS tunnels to provide any to any connectivity among Provider Edge (PE) devices.
At the network ingress, a PE device encapsulates the user traffic with the VPN header and
transports it over one or more tunnels to an egress PE device. When applied to this use case
(refer to Figure 9), SR offers several benefits including (a) simple operation through ability to
automate tunnels set up using only IGP without requiring any other signaling protocols such
as LDP or RSVP (e.g., the operator only needs to configure node segment per PE and the SR
IGP control-plane automatically setup the tunnels) (b) ECMP-aware tunnels (e.g., see [46] [47])
(c) improved scalability as the network needs to maintain much less state (e.g., one Node-SID
per PE device). In the context of IP/MPLS VPN, the main objective of ECMP-aware routing
is to allow efficient utilization of the IP/MPLS core network resources and reduce the risk of
congestion. Multi-pathing techniques such as ECMP are widely deployed in Service Provider,
enterprise, and data center network architectures [46], [47]. In these network architectures, one
of the key network efficiency metrics is to spread the traffic among maximum number of ECMP
paths.
B. Traffic Engineered Transport Paths for L2VPN and L3VPN Services
There are numerous applications and services running over MPLS networks which require
strict SLA requirements such as latency, bandwidth, or loss for the end-to-end paths used to
19
carry their traffic. In SR, IGP Segments are the basic building blocks which can be combined to
steer packets along a traffic engineered path. SR provides a mechanism by which the data plane
of a MPLS network can be programmed to realize paths meeting the required SLAs constraints.
TE topology contains additional information about link attributes such as latency, bandwidth,
SRLG, and so forth. The centralized or distributed path computation entity uses TE topology
to compute Constrained Shortest Path First (CSPF) paths. In the case of a distributed path
computation approach, an ingress node (also referred to as the head-end) calculates the shortest
path for a destination subject to certain constraints. In a centralized path computation approach,
a centralized entity such as the SDN controller computes the path. An SR-TE path consists of
one or more IGP SID(s) representing node or adjacency segments. The SDN controller uses the
Path Computation Element Protocol (PCEP) message to convey the computed SR-TE path as
an Explicit Route Object (ERO) object to the head-end node. The Link-State Database (LSDB)
contains network topology (links and nodes) only within an IGP area. In order to compute end-to-
end SR-TE paths across multiple areas (or multiple autonomous systems), the computing entity
needs the latest information about IGP network topology and SIDs. The SDN controller learns
this information by using the BGP-LS mechanism. Thus, SDN centralized path computation
approach has the added benefit of allowing computation of inter-area and multi-domain SR-
TE paths [35]. An illustration of SR-TE paths is provided in Figure 10. The network operator
configures Node-SID 102 on PE2, Node-SID 103 on P3, and Adj-SID 2001 on the link between
P3 and P4. These SIDs are propagated within the domain by the SR IGP control plane. The
SDN controller gathers the IGP TE topology information and the IGP SIDs by listening to the
BGP-LS updates and passes on this information to the PCE. An application requests the SDN
controller for a path from PE1 to PE2 subject to constraints such that the path must avoid PE1-P2
link and must use P3-P4 link. SDN controller invokes the PCE to process this request. The PCE
runs the CSPF on the TE topology database and computes the path as segment list 103, 2001,
102. The SDN controller then uses the PCEP message to pass on the computed SR-TE path as
an SR-ERO to program the PE1. The head-end then steers the traffic over the SR-TE tunnel.
C. Fault Resilient SR Paths for L2VPN and L3VPN Services
IGP segments can be used to provide resilient SR paths that allow protection against a
particular component (e.g., link or node) failure or any component failure along the path. When
protection is performed by the node adjacent to the failed component, it is commonly known as
20
Fig. 10: Illustration of an SR-TE tunnel set up using the SDN controller
local protection or Fast Reroute (FRR) technique. In contrast, when protection is performed by
the ingress node, it is referred to as path protection. Figure 11 illustrates an SR path protection
scheme. In this example, an application requests path protection for a service. The SDN controller
requests the PCE for link and node disjoint or Shared Risk Link Groups (SRLGs) disjoint paths
from PE1 to PE2. The PCE computes the node/link disjoint primary and backup paths. The SDN
controller programs the primary and backup paths on PE1. Initially, PE1 steers traffic along the
primary SR tunnel. When the primary SR tunnel fails, PE1 reroutes traffic along the backup SR
21
Fig. 11: An illustration of SR path protection scheme
tunnel.
D. Data Plane Monitoring of SR Paths for L2VPN and L3VPN Services
SR allows a scalable and simple method to monitor data plane liveliness of paths. Suppose
PE1 wishes to monitor data plane liveness of a SR path from PE1 to PE2 as depicted in Figure
12. This requires setting up a continuity check of the path to be monitored from PE1 to PE2.
The SDN controller constructs the SR-ERO 103, 2001, 102, 101 for the desired path monitoring
and programs the PE1. In order to monitor the path, PE1 periodically sends packets using the
segment list 103, 2001, 102, 101. These path monitoring packets are steered along the monitored
path from PE1 to PE3 and back to PE1. In the event of a failure along the monitored path, PE1
22
Fig. 12: An illustration of SR path data plane monitoring
does not receive reply back which allows PE1 to detect data plane failure along the monitored
path.
IV. SR PATH E NCODING I MPLICATIONS
As described earlier, SR encodes a path (an ordered list of segments) as a stack of labels
over MPLS data plane. The label stack depth that a source node needs to push in the packet
header depends on the network topology and the granularity of steering required along the
path. In general, Adj-SIDs enable granular hop-by-hop traffic steering, but constructing segment
lists using Adj-SIDs requires deeper label stacks as compared to node (or prefix) segments as
illustrated in Figure 13. To fully exploit SR flexibility for a variety of use cases, a source node
23
Fig. 13: An illustration of segment list depth for two paths over a network topology
needs to be able to push large segments list in order to realize long explicit paths across the
network. However, currently most equipment vendors’ hardware can support a limited label
stack depth (about 3 to 5 labels) [48]. A limited label stack depth restricts the ability of
a source node to realize long optimal explicit paths. This compels the source node to steer
traffic along short suboptimal paths. This, in turn, may lead to inefficient traffic distribution
and network congestion. Therefore, in SR networks with limited label stack depth capabilities,
path computation algorithms must consider the segment list depth constraint in addition to the
traditional constraints such as link cost, latency, bandwidth, and ECMP.
Several studies have proposed special algorithms for segment list computation to address the
above issues by joint minimization of the segment list depth and the packet overhead. The SR
algorithms that compute optimal path with the minimum segment list are referred to as the label
encoding algorithms. As an example, the authors in [48] have proposed an efficient algorithm
to compute the ECMP optimum paths using an auxiliary network graph while considering some
IGP metrics such as number of hops and latency. It assumes that all shortest possible paths from
any node to any node in the network are pre-calculated and held in an existing set during the
initialization phase or after topology realignment. The paths are computed with IGP metrics and
the SIDs are advertised using IGP protocol. After calculation of the path P, an auxiliary network
G is constructed using the nodes and links that belong to P. After computing the path P, another
path computation is applied on the auxiliary graph G, where paths with a higher number of hops
than the maximum Segment List Depth (SLD) threshold are rejected. The candidate paths are
first sorted with respect to the original metrics, then with respect to their length, where shorter
24
paths are more granular. The resulting paths are the concatenation of physical and virtual links,
where physical links are assigned to the adjacent Adj-SIDs and the virtual links are mapped to
their tail end Node-SIDs. The work in [48] have shown a novel label encoding algorithm for
constructing the segment list for the path. The algorithm is tested against ECMP and multiple
constraints and it guarantees optimal path calculation with minimum SLD.
The work done in [49] has also proposed an optimum path encoding technique using the auxiliary
graph to model the network. Their work has exploited the segment list encoding to implement
TE solutions. The detailed problem formulation and the proposed solution are described, along
with the performance evaluation.
Another work in [50] has tackled the problem of Label Encoding for SR-MPLS while considering
the Maximum SID Depth (MSD) that the hardware resources support. The currently existing
equipment’s support an average of 3 to 5 MSD, which imposes limitation on the number of paths
that are implemented in SR-MPLS. This limitation might cause inefficient resource utilization
in the network, which in turn increase the potential of network congestion. Two efficient label
encoding algorithms SR-LEA and SR-LEA-A are proposed in [50] to leverage the IGP shortest
paths that exist in the network. Both algorithms are proven to calculate the minimum label stack
that is required to express the existing paths in accordance to the MSD that the target hardware
can support. Several other works have tackled SR Path Encoding issue. As an example, the work
done in [51] has proposed a solution where all the possible shortest paths to the destination are
calculated using ECMP, and the label stack is computed using two proposed algorithms. Both
proposed algorithms are designed to navigate the alternative paths towards the destination to
perform comparison in terms of the Segment List Depth (SLD) and the packet overhead. The
paper shows a detailed comparison between the two proposed algorithms [51]. A summary of
the different label encoding algorithms in segment routing is shown in Table II. Finally, the work
in [52] defines the notion of Binding SID (BSID). A BSID is bound to a SR policy path (where
the path is represented by a SID list). The source node encodes the SR policy paths (i.e., the
associated segment list) with a single BSID. In summary, a BSID enables decoupling between
domains and helps to decrease the number of segments that needs to be imposed by the source
node as illustrated in Figure 14.
25
Fig. 14: An illustration of BSID usage for reducing the segment list depth [52]
TABLE II: Comparison of label encoding algorithm in segment routing
References Performance metric Constraints Optimization strategy

[48] Segment list depth Bandwidth, Latency Heuristic
[49] Segment list depth, Packet overhead Multi-commodity flow algorithm
[50] Segment list depth Maximum segment list depth Heuristic
[51] Segment list depth, Packet overhead Heuristic
V. SR A PPLICATIONS
As described so far, applying SR in regular networks can achieve improvements at different

levels. This is due to the rich set of capabilities that the SR enables such as traffic engineering,
packet restoration and duplication, service function chaining, network monitoring, application in
data centers and multi-domain routing as discussed in the following sections.
26
A. Traffic Engineering (TE)
Studies show that exploiting SR ECMP in traditional networks using IGP shortest paths may
lead to high resource utilization and congestion under some traffic conditions in spite of the
available capacity in the network [53]. These drawbacks led to the introduction of Traffic
Engineering in SR. TE can be defined as a set of strategies and principles that are applied
in the network for effective placement of traffic in a network to improve network operational
efficiency [54]. SR provides a flexible set of capabilities for traffic engineering with granular
control. An SR traffic engineered (TE) path consists of an ordered segment list containing one
or more SIDs where each SID may represent a node, an adjacency, a policy, and so forth. The
mechanism for expressing an SR path as an ordered list of segments, programming a source
node with the segment list, and steering traffic along the SR path is referred to as SR traffic
engineering (SR-TE). The path computation function in the SR-TE can be performed using a
distributed approach where a source node computes the path or a centralized approach where
Path Computation Element (PCE) in the controller computes the path and then programs the
source node with the path (for an illustration, refer to Figure 10). An SR policy contains one or
more candidate paths from a source node to endpoint. Each candidate path has a preference. The
SR-TE path selection process selects the best path from the candidate paths based on preference
value. The selected best path is installed in the forwarding information base (FIB). An SR policy
entry in the FIB is looked up using BSID as a key. Any packet which matches the policy key
is steered along the selected path represented as an ordered list of segments [52]. TE allows to
achieve several network performance objectives as described in the following sections.
1) Congestion minimization: Congestion minimization is one of the critical problems in TE
context, since it has direct effect on packet loss, jitter or delay. And it relies on balancing the
traffic load in the network through splitting the traffic into multiple streams and steers them in
separate calculated paths. This TE objective can be achieved through different methodologies,
which are described below:
• Sharing the available resources by several traffic streams in the network.
• Reallocating the network resources through distributing the existing traffic in the network.
• Detecting the congestions, restricting access to congested resources, and assigning the new
traffic demands to the underutilized resources.
Congestion minimization is a common TE goal that directly impacts other performance objective,
27
since it results in less packet loss and minimized end-to-end delay. The work introduced in [55]
has discussed TE methodology specially in 2-segment routing, where the traffic flows between the
ingress and egress nodes through exactly one intermediate node. In their work, the problem of TE
is discussed in three categories, namely, Traffic Matrix Aware Segment Routing, Traffic Matrix
Oblivious Segment Routing, and The Online Segment Routing. In Traffic Matrix Aware SR, it is
assumed that the traffic from node i to node j is known and the goal is to split the traffic across
different segments between each pair of nodes to perform TE. While in Traffic Matrix Oblivious
SR, the traffic matrix is not known in advance, and the traffic is well distributed among a wide
range of matrices. The last scenario, Online SR, assumes knowledge of the network current state
along with the link loads without knowing the future traffic arrivals, and it aims to reject as few
requests as possible. The work in [55] has shown that Segment Routing outperforms the shortest
path routing by minimizing the maximum link utilization in order to avoid network congestion.
Different algorithms have been proposed to solve the intractable problem of computing the TE
paths in segment routing [55]–[59]. Bhatia et al. [55] used ILP technique to find 2-segment
routing path, where any logical path contains only one middle point and thus two segments.
However, ILP technique is not scalable. Hartert et al. [56], [57] proposed some heuristics and
hybrid constraint programming framework to compute forwarding paths for TE in SR. The
authors in [58] proposed a polynomial time heuristic by selecting few important nodes as middle
points for all traffic. For the selection of middle points, the authors exploited the node centrality
concept from graph theory and social network analysis field. The proposed algorithm achieved
good results with orders of magnitude lower runtime as compared with [55]. Gay et al. [59]
approach is based on local search with focus on the quick re-arrangements of few forwarding
path for sub-second re-computation of segment-routing paths that comply with requirements on
the maximum link load for congestion avoidance.
2) End-to-End delay minimization: End-to-end delay is a performance objective that affects
the QoS and Quality of Experience (QoE). End-to-end delay is considered as a critical metric
in real-time communications and applications. CSPF is considered as one of the most common
techniques for minimizing end-to-end delay [54]. The authors in [60] have proposed another TE
use case where no enhancements are required in the intra-domain routing protocols (OSPF, IS-
IS). Their work aims to avoid extending the routing protocol to support the SIDs distribution, and
it focuses on using the global Adj-SIDs that are automatically generated by nodes to perform TE.
The authors also ensured the optimal path computations in terms of the number of segments that
28
are required for path representation. Additionally, they have verified that the required execution
time is less compared to the TE heuristics of traditional hop-by-hop paths, which ensures a
minimized end-to-end delay that is crucial to the real-time communications. Moreover, the work
done in [49] have conducted a proper formulation of the segment list in path encoding literature,
which leads to a better TE outcome with respect to the cost of configuration in terms of end-
to-end tunneling and hop-by-hop solutions.
3) Energy consumption minimization: This objective is widely used in the scope of green
computing, which reduces the impact of Information and Communications Technology (ICT)
on the environment. Generally, the routing protocols play an important role in the TE literature,
therefore it has an impact on the energy management in the network. Routing protocols in IP
networks can be classified into two different categories: Flow based and shortest path based
protocols. In flow based routing, the traffic is routed through one or more dedicated paths, as in
the MPLS networks. When shortest path routing is adopted, the shortest paths are determined
according to links weights. Therefore, TE techniques aiming at minimizing the energy consump-
tion can be performed by adjusting link weights and by diverting the traffic from the sleeping
nodes [61]. An energy efficient TE solution was introduced by the authors in [62] by selectively
turning on/off any subset of links in the backbone network. Their proposed solution enables
the traffic load to dynamically adapt to the available operating links that leads to an improved
TE. Similar work was conducted in [63] especially in intra-domain SDNs. In this work, SR
technique is shown to lead to faster convergence of the algorithm that changes the status of the
existing router ports and transponders to reduce the consumed energy in backbone networks.
The technique relies on computing new routes to either avoid or reuse the links, selecting links
to turn on/off, and then reroute the flow on the newly computed paths. This work has taken into
consideration the divergence of opinions regarding the centralized and distributed approaches,
and it shows an improvement in the stability of energy efficient TE approaches by applying SR
[64]. In this context, the application of SDN with a centralized view of the network topology
allowed to simplify and improve efficiency of the TE solution.
The authors in [64] have proposed a TE solution in SDN where SR technique is applied to
enhance the performance. SR enables the network to classify and steer the flow to a given path
at the ingress router, so that the underutilized links are turned off to save energy effectively.
In their approach, the SDN controller is assumed to collect the information of link utilization
every second. After the implementation, it was shown that sudden traffic bursts may lead to
29
congestion which required need to turn on the previously shut links. To address this issue, an
algorithm was proposed to quickly switch on links when traffic bursts are detected to reduce the
possibility of potential packet loss. The performance of their approach was tested with discrete-
event simulation, and it was shown that the application of SR in SDNs enhanced the efficiency
of TE [64]. The authors in [65] have proposed a green SDN-based SR scheme for IEEE802.3az
Ethernet links.
4) Resource utilization optimization: This objective assures the efficient use of the network
resources such as bandwidth, computation, and buffer space. The efficient utilization of network
resources can lead to serving higher number of traffic demands without increasing the network in-
frastructure cost [54]. Moreover, this objective impacts other aspects such as network congestion.
The work in [66] addresses the application of TE in SR where the network control is centralized
as in SDN. Their model is an ISP network managed by an enhanced SDN controller, where each
node is assumed to be MPLS capable node and is categorized either a Provider Edge (PE) routers
or a Core Router (CR). PE nodes are allowed to originate and terminate connections whereas
both PE and CR nodes can be intermediate nodes in the path. Their enhancement is achieved
by applying SR-TE features to the applications through the NBI. The approach assumes that the
SDN controller is responsible for allocating a specific bandwidth to a set of traffic flows, with
prior knowledge of link capacity. Thereafter, the hop-by-hop TE paths are first allocated using a
basic TE algorithm [66]. Secondly, a corresponding SR path for each TE path is computed using
their proposed heuristic. Their approach offers service based either on SR-TE forwarding or the
traditional hop-by-hop MPLS-based LSP forwarding. To further enhance the performance of TE,
the authors in [53] have proposed a heuristic and ILP model that exploit the SR approach. They
showed that the default behavior in SR that exploits the ECMP may lead to several drawbacks
such as higher network resource utilization. For this reason, the default behavior of SR (which
makes use of ECMP) was avoided in their work to perform more efficient TE. The authors in [67]
exploited SR in SDN in order to optimize network performance and network resource utilization
by taking into consideration the link capacity and path length. A comparison of different TE
techniques in segment routing is shown in Table III.
B. Recovery from Failures
The nature of SR paradigm permits a better control on the routing paths by steering the traffic
into different paths, which leads to an improved network utilization. The existence of a central
30
TABLE III: Comparison of TE techniques in segment routing
References TE Objectives Constraints Optimization Strategy

[53] Resource utilization Segment list depth ILP, Heuristic
[55] Network congestion ILP
[56], [57] Network congestion Hybrid constraints programming framework
[58] Network congestion Heuristic
[59] Network congestion Time Local search
[62], [63] Network congestion Time Local search
[64] Resource utilization Link capacity Heuristic
[65] Energy consumption Congestion threshold Heuristic
[67] Resource utilization Link capacity, Path length Heuristic
controller in SR helps exploit its potentials by choosing segments according to the traffic pattern.
The choice of segments allows to distribute the traffic in the network in a manner such that it
lowers the chances of having hot-spots. The use of IGP routing protocol in SR enables the
failure recovery and restoration mechanisms in a distributed manner since it re-computes the
shortest paths upon failure. To implement this distributed restoration scheme, it is assumed that
the network is planned in such a way that there exists enough capacity in the network to reroute
the traffic upon any failure. In [68], an initial segment configuration is proposed such that there
would be sufficient network resources to reroute the traffic in case of failure. Their work presents
an approach to handle the case of single shortest path failure and generalize this approach to
handle failures along ECMP routing. Also, their work provides a mechanism to recover from
multiple link failures that occurs at the same time, which is known as Shared Resource Link
Group (SRLG) failures. To implement an effective restoration scheme, an efficient sharing of
bandwidth must be realized among different failures. In their approach, this is achieved by
splitting the traffic on a given link into the primary traffic and the restored traffic. The primary
traffic is the real traffic that flows through the links where no failures exist, whereas the restored
traffic is the traffic that flows on that link as a result of a failure restoration. Their work in [68]
includes a detailed calculation of the appropriate bandwidth that must be reserved for each type
of traffic on the link, so that the restoration feature is implemented properly.
An alternative solution is proposed in [34], [69] to recover from failures dynamically with
minimized Segment List Depth (SLD), where the central controller is not involved in the recovery
process. The nodes are configured properly during the initialization of the network, such that
31
they are able to locally redirect the flow on a backup path upon the failure of a connected
interface. This network initialization might be performed in distributed manner using either an
extended IGP or an SDN centralized controller. The author’s main focus is to provide a primary
forwarding tables as well as the failover forwarding tables for each interface in the node. For
each ingress label in the segment list, there exists an output port that is kept in the primary table.
Upon the output port failure, the backup actions that are held in the primary table are executed,
as the node discards all segments in list except the segment at the bottom of the list, which is
the destination label. The processed packet is passed to the appropriate failover table where all
the actions relevant to the value of the bottom label are executed. All the pre-computed shortest
paths are utilized by the failover table for each link. Their scheme provided a dynamic packet
restoration technique that exploits the concept of SR [69]. The same authors extended their work
in [70] to evaluate the recovery technique to the node failure scenario and provided additional
experimental results.
C. Traffic Duplication for Protection
Traffic transmitted through the network can be of critical nature. Protecting the path followed
by such mission-critical traffic is crucial to ensure a continuous transfer of traffic in order to
avoid revenue loss. Traditional networks handle the critical traffic using classic solutions for
traffic protection, such as sending redundant information over disjoint paths. In optical network,
traffic protection is provided using two techniques 1:1 and 1+1, where two disjoint paths are
used between the communication nodes in both techniques. The first technique, 1:1, the traffic
is sent over the primary path and upon failure it is switched to the pre-reserved secondary path.
With 1+1 protection scheme, the traffic traverses both disjoint paths and the destination switches
to the secondary path upon the failure of the primary one. The aforementioned techniques are
rarely used in TCP/IP networks, as TCP relies on acknowledgments and retransmission of the
lost data for recovery. The authors in [71] have proposed a protection solution in IPv6, where
1+1 technique is applied on end to end paths. Their proposed solution starts with duplicating
the traffic at the ingress node toward a given destination. The ingress node inserts different SR
headers in the packets so that it can be steered towards the same destination using disjoint paths.
A special algorithm is used to calculate the link and node disjoint paths, where the resulting
paths are implemented as a sequence of segments and are called ’Segmentable Disjoint Paths’.
After paths computations, the router knows in advance which SR header to use for any desired
32
destination. The algorithm is implemented either in a centralized controller or in a distributed

manner in the router itself. In general, traffic duplication should be used in low-volume and
delay sensitive operations due to high cost associated with extra capacity required in the network.
Instead of sending all the packets that belong to a given flow over a single path, the disjoint paths
in SR have been exploited for traffic dispersion [72] to counter pervasive traffic monitoring.
D. Service Function Chaining (SFC)
A network service refers to an end-to-end offering that an operator delivers by using one or
more service functions. A service function performs a specific treatment on packet that it receives.
The end-to-end service delivery of service may require one or more service functions. A non-
exhaustive examples of service functions include firewalls, WAN and application acceleration,
Deep Packet Inspection (DPI), server load balancing. In networks, different services are provided
by a number of independent operators that are implemented using appliances. These appliances
are frequently updated, replaced or migrated to ensure users satisfaction. However, the tight
integration of appliances with the network devices introduces a management and maintenance
overhead. To address these issues, an approach known as Service Function Chaining (SFC) is
proposed [73], [74]. SFC refers to an ordered sequence of abstract service functions and ordering
constraints that must be applied to packets flows selected as a result of classification. SFC
decouples the constraint associated with physical topology based service function, by realizing
a Service Function Path as an ordered list of service functions encoded in the packet header.
SR architecture is well suited for SFC applications as it provides flexible capabilities to implement
SFC on MPLS and IPv6 data planes. Specifically, SR can create an ordered segment list to
represent an ordered list of service function, encode this information in a packet header, and steer
the packet along a specific path so that the packet receives the required service function treatment
in the specified order [18]. An illustration of SFC realization using SR is depicted in Figure 15.
In a cloud networking environment, application endpoints are user devices and virtual machines
which can be hosted in geographically dispersed locations. SDN combined with SR promises
to make deployment of dynamic SFC a reality through network automation, programmability,
and agility capabilities. Consequently, virtual service functions can be interconnected at a large
scale using virtual connections which can be set up and torn down on demand by provisioning
SFC through SDN orchestration. This enables network operators with existing distributed network
infrastructure and hosting centers to offer compelling on demand and elastic end-to-end services.
33
In a cloud based environment, each application can generate a large number of low bandwidth
flows (i.e., termed as MicroFlows). Each MicroFlow may require traversing different set of
service function chains. It is not desirable to map an individual MicroFlow to a separate SR
path as this does not scale. Therefore, one of the challenges is dynamically steering multiple
MicroFlows with the same set of service functions onto a single SR path at the network edge
at a MicroFlow level granularity. The authors in [75] have extended BGP FlowSpec to support
MicroFlow chaining using SR in a multi-layer network setting. Using the proposed approach,
when a new flow request arrives, the Flow Computation Module (FCM) identifies one or more
established SR paths for steering the flow. In the event the new Flow cannot be served using
one of the existing SR paths (e.g., due to insufficient bandwidth), setting up a new SR path is
initiated at the PCE. The use of SR to support SFC in Network Function Virtualization (NFV)
scenario has been reported in [76]. In summary, SFC technology facilitates the deployment of
dynamically created virtual services that are supported by NFV model, which are gaining high
acceptance in the industry [77].
E. SR based Network Monitoring
Remote network monitoring devices send special packets called probes to monitor a network.
On-demand and proactive monitoring of network data plane paths is crucial for rapid fault
detection, localization, and service validation. Network operators extensively employ multipath
schemes such as ECMP and Link Aggregation Group (LAG) in order to scale capacity of their
networks [78]. While multipath schemes enhance network scalability and availability, they pose
following challenges for network monitoring. First, it is hard to monitor parallel links (or paths)
at per link (or per path) granularity. This is because with ECMP different packets of a flow
can be forwarded on different paths depending on results of hashing flow-related fields in the
packet header. Furthermore, as different hashing techniques could be employed by each node
along the path, it becomes difficult to reproduce and localize a failure in a consistent manner.
Some probes might fail while others might succeed. Second, traditional network monitoring tools
are not scalable (e.g., typically require sending/receiving and synchronizing probes on multiple
paths from multiple vantage points) and unable to steer probes along an explicit path. While it
is possible to utilize RSVP-TE tunnels to steer probes along specific paths, it is not scalable
option as this would require keeping large amount of state information in the network. SR is well
suited for network monitoring as it allows steering of packets along pre-defianed paths which
34
Fig. 15: An illustration of SFC realization using SR
enables a centralized monitoring system to perform a continuity check along all Label Switched
Paths of the SR domain [26]. The authors in [79] have proposed a new monitoring scheme called
SCMon which relies on SR. SCMon discovers network topology containing all nodes and links in
the network. It runs specific algorithms that compute the monitoring cycles and the monitoring
topologies that span all the existing links. Each cycle is represented as a segment list. The
cycles are selected such that each cycle length is below the specified limit of maximum number
of segments. SCMon performs the detection and localization of links failures or congestion by
tracking the cycles in which the probes are sent and not received by the monitoring system.
35
The study in [79] showed that the SCMon scheme effectively monitors the network containing
multipaths and can pinpoint failure locations rapidly (in order of few milliseconds).
F. SR in Large Scale Data Centers
A data center refers to a facility that houses large scale hardware equipment to provide
computer, storage, and networking resources. Large scale data center networks typically deploy
multi-rooted CLOS topologies with a large number of parallel paths to provide high bandwidth,
low latency, and non-blocking server-to-server connectivity. The data center networks utilize
shortest-path routing with ECMP to load-balance traffic among parallel paths where every
network device maps packets to one of its outgoing parallel paths by applying a hash function on
selected fields in the packet header. One of the performance drawbacks of data center network
architecture stems from the shortest-path ECMP oblivious routing behavior which is unaware
of congestion along a path and can create hotspots in the network. SR with the centralized
controller enables proper load balancing traffic among paths. This helps to avoid the drawbacks
associated with the oblivious ECMP hashing. For instance, if some links or nodes in the data
center network start dropping packets due to a fault, the controller could monitor the network
and detect the failed path(s) and program the source node to steer traffic away from the failed
paths. The data center network design analysis in [80] shows that application of SR in large
scale data centers enables additional benefits including simplification of the MPLS data plane,
reduction of the IP FIB tables, traffic engineering of data center outbound traffic on a per flow
basis, without requiring any additional state at intermediate nodes in the data center network.
G. Multi-Domain SR Networks
SR TE can be applied across multi-domains (i.e., multiple IGP areas, multiple autonomous
systems) by gathering multi-domain link-state and TE topology information. The SDN controller
can collect link-state and TE information from multi-domain networks using BGP-LS and
employ the PCE mechanism to compute an end-to-end SR-TE path, as illustrated in Figure
16. In a multi-domain scenario, the computation of an end-to-end path can be a problem
since a single point of path computation may not be aware of the topology information in
each domain. This can be addressed by using a hierarchical PCE architecture where PCEs are
organized in a parent and a child relationship [81]. A parent PCE maintains an abstract view of
domain topology map in which child PCEs are represented as vertices in the topology and their
36
Fig. 16: An illustration of end-to-end SR Deployment in intra and inter-DC use cases
interconnections represented as links in the topology. To meet the confidentiality and scalability
objectives, the parent PCE avoids the need to know information details (e.g., resource availability,
interconnectivity) within the child domains. In contrast, a child PCE only knows the topology
details of the domain that it serves. Each child PCE computes a set of candidate path segments
for its domain and passes the results to the parent PCE which then derives a multi-domain end-
to-end path.
The work in [82] describes application of the SR PCE for computing end-to-end paths in multi-
domain use cases involving interconnection of massive-scale data center and large aggregation
metro networks. The work in [35] demonstrates the orchestration of multi-domain SDN using
SR. This work proposed a hierarchal control plane architectures for multi-domain SR networks.
Additionally, it provides a methodology to exchange SID information in multi-domain scenarios.
The hierarchal architecture enables the orchestrator to compute end-to-end SR-TE paths by
using available resources and existing policies of each domain. The orchestrator maintains an
abstract view of the unified topology and resource availability based on only SIDs to ensure
37
the confidentiality of intra-domain topology related information. After capturing the topologies
of all domains, the orchestrator runs specific algorithms to determine the border nodes and
the intra-domain connectivity to calculate the best feasible paths using prefix of Adj-SIDs.
This implementation provided flexibility and scalability while insuring the control over paths
constructions to cope with the existing policies. In contrast, a bottom-up approach for multi-
domain SR architecture is proposed in [83] to combine existing technologies and domain-specific
orchestration. This approach has fulfilled the industry requirements and the standard associations
such as NGMN, ITU-T FG IMT-2020, and IMT-2020(5G). The authors in [84] have also
conducted a novel network monitoring system based on the multi-domain orchestration. Their
work leveraged the SR technique to measure the unidirectional delay statistics on real network
environments.
VI. C HALLENGES AND F UTURE W ORK
SR provides a very flexible architecture and it has been extensively studied in the industry
for a broad set of applications. However, several challenges still remain that opens interesting
research opportunities for future work.
When SR is instantiated over IPv6 data plane (aka SRv6), the source route instruction information
is encoded as an ordered list of 128-bit long IPv6 addresses and contained in the SRH. The
work in [33] has proposed a new SRv6 network programming model and the associated set of
operations to support various applications. Some of the possible drawbacks of this approach
include potentially large overhead associated with using 128-bit long segment list and the
requirement for new forwarding logic and semantics. Most currently deployed hardware systems
may be unable to support without degradation in the forwarding performance. The work in [85]
has proposed an MPLS-based unified source routing instructions approach for realizing SR for
both IPv4 and IPv6 data planes leveraging the existing hardware systems. An interesting area
of future research could be to study trade-offs between the two approaches in terms of their
cost, scalability, and applicability in emerging cloud scale applications environment such as
IoT. SDN provides useful features to achieve proficient multicasting in order to efficiently offer
QoS constraints emerging web-based services [86]. SR opens up new exciting opportunities for
scalable and flexible multicast services [87].
The work in [88] proposes a framework (termed as in-band telemetry) for collecting and reporting
network state (e.g., ingress and egress port, queue length, per node latency) by encoding this
38
information in the packet header without requiring intervention or processing by the control
plane. The work in [89] provides requirements and numerous potential use cases for in-band
OAM. When SFCs are deployed without a proof-of-transit mechanism, they are operated in the
fail-open system (i.e., packets at the end of the chain are processed under the assumption that it
traversed the required service functions while in reality it may not have). The addition of proof
of transit capabilities (i.e. proof that a packet indeed traversed a specific set of SFCs) allows an
operator to deploy SFCs in a more secured manner as a fail-close system and block any packets
without a valid proof of transit. This helps to reduce the risk of anomalous or malicious traffic
passing undetected. Another area of future research could be to study SR architecture extensions
for in-band telemetry to enable proof-of-transit capabilities for SFC applications.
An interesting future direction worth exploring is the network monitoring in SR, where the
length of monitoring cycles must be adequately chosen such that the resulting cycles are of
appropriate number and length. Several works have tackled this open issue but some aspects are
still not considered. The bounded cycles problem is an NP-complete problem that was addressed
in details in [90], [91]. This creates an opportunity to develop better heuristic approaches which
can consider tradeoff between the solution quality and running time. The authors have shown that
the number of the cycles in the network grows exponentially as a function of the allowed cycle
length and the number of existing nodes. Therefore, network-partitioning techniques [92] are
essential to create smaller zones in large-sized networks, so that the required cycles number and
length are minimized. The work in [93] introduces a novel scheme for partitioning the network
into several management areas and monitors each partition separately.
It could also be very useful to explore architectural extensions of SR beyond IP/MPLS networks
to transport SDN networks including optical transport network (OTN) and dense wavelength
division multiplexing (DWDM) / reconfigurable optical add-drop multiplexer (ROADM) layers
[94], [95]. In particular, an interesting direction for further exploration could be to study SR
extensions to a multi-layer SDN environment to yield an overall cost efficient (i.e., reduced
network infrastructure cost, improved network efficiency) network solution.
The optimization approaches in the networks are yet to be studied in centralized vs. distributed
manner especially in SR literature. There are also some challenges related to security in SFC
which leaves it vulnerable for attackers, especially by the distributed Denial of Service Attacks.
Additionally, the reliability and availability in SFC is mandatory since the dynamic addition or
removal of services must be performed without interrupting other services. Furthermore, SFC
39
plays a major role in the deployment of IoT [77], where it should provide interoperability among
the large number of communicated heterogeneous sensory devices in IoT paradigm.
VII. C ONCLUSION
The phenomenal growth of Internet traffic and emerging applications demand high capacity
and high performance networks, which poses new challenges regarding network manageability
and scalability. To respond to these challenges and replace (or complement) the current inefficient
destination based routing schemes, an emergent and highly flexible SR paradigm was introduced
by the IETF. SR solves the network challenges by steering along performance engineered paths
represented as an ordered list of instructions called segment list and encoded as a MPLS label
stack or an IPv6 address list in the packet header. SR maintains per-flow state only at the
ingress node, where segment list is applied. The segment list has sufficient information to steer
the packets from the ingress node to the egress node of the path. Therefore, SR eliminates the
need of keeping per flow state information on every node along the path; this greatly improves
network scalability by reducing the flow table size stored in TCAM. SR obviates the need
for any additional signaling protocol (e.g., LDP and RSVP-TE), simplifying the control plane.
SR allows service provider to reduce overall network cost through improved capacity planning
(e.g., by ensuring that most of traffic rides on node segments is routed on the ECMP-based
shortest path) and traffic engineering (e.g., by steering minority of traffic along explicit paths
while still benefiting from the ECMP-awareness provided by the node segments in the segment
list). SR enables network resiliency (e.g., path and local protection) and helps avoid forwarding
loops during the IGP re-convergence process after a network topology change event (e.g., a link
down/up event) [96].
Since SR is an important and growing area of research, in this work, we presented a com-
prehensive survey that covers the SR architecture, operation, as well as how it copes with the
existing network architectures to date. We started with an overview of the basic concepts and
unique features of SR architecture. Then, we examined the techniques to effectively construct
the label stacks that represent the explicit paths in SR. Next, we looked into a broad set of SR
applications including TE techniques, restoration from failures, traffic protection, service function
chaining, network monitoring, data centers and service provider networks. For these applications,
SR showed better performance as compared with the traditional routing schemes with respect to
performance metrics such as link utilization, network resiliency, energy consumption, and end-
40
to-end delay. Finally, we discussed compelling research challenges and open issues that could
make the best use of an innovative SR paradigm.
ACKNOWLEDGEMENT
The authors would like to thank the anonymous reviewers for their invaluable and thoughtful
comments which definitely improved overall quality of the manuscript.
41
R EFERENCES
[1] M. Al-Fares, A. Loukissas, and A. Vahdat, “A scalable, commodity data center network architecture,” in ACM SIGCOMM
Computer Communication Review, vol. 38, no. 4. ACM, 2008, pp. 63–74.
[2] “Open networking foundation,” https://www.opennetworking.org.
[3] D. Kreutz, F. M. Ramos, P. Esteves Verissimo, C. Esteve Rothenberg, S. Azodolmolky, and S. Uhlig, “Software-defined
networking: A comprehensive survey,” Proceedings of the IEEE, vol. 103, no. 1, pp. 14–76, 2015.
[4] W. Xia, Y. Wen, C. H. Foh, D. Niyato, and H. Xie, “A survey on software-defined networking,” IEEE Communications
Surveys & Tutorials, vol. 17, no. 1, pp. 27–51, 2015.
[5] C. Trois, M. D. Del Fabro, L. C. de Bona, and M. Martinello, “A survey on sdn programming languages: Toward a
taxonomy,” IEEE Communications Surveys & Tutorials, vol. 18, no. 4, pp. 2687–2712, 2016.
[6] M. F. Tuysuz, Z. K. Ankarali, and D. Gözüpek, “A survey on energy efficiency in software defined networks,” Computer
Networks, vol. 113, pp. 188–204, 2017.
[7] W. Li, W. Meng, and L. F. Kwok, “A survey on openflow-based software defined networks: Security challenges and
countermeasures,” Journal of Network and Computer Applications, vol. 68, pp. 126–139, 2016.
[8] “Opendaylight: Open source sdn platform,” https://www.opendaylight.org.
[9] R. Enns, M. Bjorklund, and J. Schoenwaelder, “Network configuration protocol (netconf),” IETF RFC 7803, 2011.
[10] H. Gredler, J. Medved, S. Previdi, A. Farrel, and S. Ray, “North-bound distribution of link-state and traffic engineering
(te) information using bgp,” Tech. Rep., 2016.
[11] J. Le Roux, “Path computation element (pce) communication protocol (pcep),” IETF RFC 5440, 2009.
[12] C.-Y. Hong, S. Kandula, R. Mahajan, M. Zhang, V. Gill, M. Nanduri, and R. Wattenhofer, “Achieving high utilization with
software-driven wan,” in ACM SIGCOMM Computer Communication Review, vol. 43, no. 4. ACM, 2013, pp. 15–26.
[13] S. Jain, A. Kumar, S. Mandal, J. Ong, L. Poutievski, A. Singh, S. Venkata, J. Wanderer, J. Zhou, M. Zhu et al., “B4:
Experience with a globally-deployed software defined wan,” ACM SIGCOMM Computer Communication Review, vol. 43,
no. 4, pp. 3–14, 2013.
[14] A. R. Curtis, J. C. Mogul, J. Tourrilhes, P. Yalagandula, P. Sharma, and S. Banerjee, “Devoflow: scaling flow management
for high-performance networks,” in ACM SIGCOMM Computer Communication Review, vol. 41, no. 4. ACM, 2011, pp.
254–265.
[15] A. S. Iyer, V. Mann, and N. R. Samineni, “Switchreduce: Reducing switch state and controller involvement in openflow
networks,” in IFIP Networking Conference, 2013. IEEE, 2013, pp. 1–9.
[16] “Spring-open - an onf tag project,” Web site.[Online]. Available: https://wiki.onosproject.org/display/ONOS/Project+Description.
[17] C. Filsfils, N. K. Nainar, C. Pignataro, J. C. Cardona, and P. Francois, “The segment routing architecture,” in 2015 IEEE
Global Communications Conference (GLOBECOM). IEEE, 2015, pp. 1–6.
[18] C. Filsfils, D. Previdi, and S. Litkowski, “Segment routing architecture,” in Network Working Group/ Internet-Draft, no. 08.
Cisco Systems, Inc, Orange, Jive Communications, 2016, pp. 1–24.
[19] C. Filsfils, S. Previdi, A. Bashandy, B. Decraene, S. Litkowski, M. Horneffer, R. Shakir, J. Tantsura, and E. Crabbe,
“Segment r publisher=Optical Society of Americaouting with mpls data plane,” IETF Spring Working Group draft-ietf-
spring-segment-routing-mpls-00, 2014.
[20] C. Filsfils, B. Field, Previdi, I. Leung, J. Linkova, E. Aries, T. Kosugi, E. Vynke, and D. Leburn, “Ipv6 segment routing
header (srh),” IETF Spring Working Group draft-ietf-6man-segment-routing-header-05 (work in progress), 2017.
[21] C. Filsfils, B. Field, P. Psenak, Previdi, H. Gredler, R. Shakir, W. Henderickx, and J. Tantsura, “Ospf extensions for segment
routing,” IETF Spring Working Group draft-ietf-ospf-segment-routing-extensions-10 (work in progress), 2016.
42
[22] S. Previdi, C. Filsfils, A. Bashandy, H. Gredler, S. Litkowski, B. Decraene, and J. Jefftant, “Is-is extensions for segment
routing,” IETF Spring Working Group draft ietf-isis-segment-routing-extensions-05 (work in progress), 2016.
[23] P. Psenak, C. Previdi, S.and Filsfils, H. Gredler, R. Shakir, W. Henderickx, and J. Tantsura, “Ospfv3 extensions for segment
routing,” IETF Spring Working Group draft-ietf-ospf-ospfv3-segment-routing-extensions-07 (work in progress), 2016.
[24] S. Sivabalan, J. Medved, C. Filsfils, E. Crabbe, R. Raszuk, V. Lopez, J. Tantsura, W. Henderickx, and J. Hardwick, “Pcep
extensions for segment routing,” IETF Spring Working Group draft-ietf-pce-segment-routing-08 (work in progress), 2016.
[25] C. Filsfils, S. Previdi, B. Decraene, and R. Shakir, “Resiliency use cases in spring networks,” IETF Spring Working Group
draft-ietf-spring-resiliency-use-cases-08 (work in progress), 2016.
[26] R. Geib, C. Filsfils, C. Pignataro, and N. Kumar, “A scalable and topology-aware mpls dataplane monitoring system,”
IETF Spring Working Group draft-ietf-spring-oam-usecase-05 (work in progress), 2017.
[27] N. Kumar, G. Swallow, C. Pignataro, N. Akiya, S. Kini, H. Gredler, and M. Chen, “Label switched path (lsp) ping/trace
for segment routing networks using mpls dataplane,” IETF Spring Working Group draft-ietf-mpls-spring-lsp-ping-02 (work
in progress), 2016.
[28] J. Brzozowski, J. Leddy, C. Filsfils, R. Maglione, and W. Townsley, “Ipv6 spring use cases,” IETF Spring Working Group
draft-ietf-spring-ipv6-use-cases-09 (work in progress), 2017.
[29] A. Kos, “Segment routing principles and applications for sdn,” 2016.
[30] “Segment routing tutorials available,” http://www.segment-routing.net/tutorials/.
[31] C. Filsfils, K. Michielsen, and K. Talaulikar, “Segment routing part i, create space independent publishing platform.”
Create Space Independent Publishing Platform, 2017.
[32] A. Farrel and R. Bonica, “Segment routing: Cutting through the hype and finding the ietf’s innovative nugget of gold,”
IETF Journal, vol. 13, no. 1, pp. 5–9, July 2017.
[33] C. Filsfils, “Srv6 network programming,” IETF Spring Working Group draft-filsfils-spring-srv6-network-programming-00
(work in progress), 2017.
[34] A. Giorgetti, A. Sgambelluri, F. Paolucci, and P. Castoldi, “Reliable segment routing,” in Reliable Networks Design and
Modeling (RNDM), 2015 7th International Workshop on. IEEE, 2015, pp. 181–185.
[35] N. Kukreja, R. Alvizu, A. Kos, G. Maier, R. Morro, A. Capello, and C. Cavazzoni, “Demonstration of sdn-based
orchestration for multi-domain segment routing networks,” in Transparent Optical Networks (ICTON), 2016 18th
International Conference on. IEEE, 2016, pp. 1–4.
[36] L. Luo, H. Yu, S. Luo, M. Zhang, and S. Yu, “Achieving fast and lightweight sdn updates with segment routing,” in Global
Communications Conference (GLOBECOM), 2016 IEEE. IEEE, 2016, pp. 1–6.
[37] S. Bidkar, A. Gumaste, P. Ghodasara, S. Hote, A. Kushwaha, G. Patil, S. Sonnis, R. Ambasta, B. Nayak, and P. Agrawal,
“Field trial of a software defined network (sdn) using carrier ethernet and segment routing in a tier-1 provider,” in 2014
IEEE Global Communications Conference. IEEE, 2014, pp. 2166–2172.
[38] D. Cai, A. Wielosz, and S. Wei, “Evolve carrier ethernet architecture with sdn and segment routing,” in World of Wireless,
Mobile and Multimedia Networks (WoWMoM), 2014 IEEE 15th International Symposium on a. IEEE, 2014, pp. 1–6.
[39] A. Sajassi, R. Aggarwal, N. Bitar, A. Isaac, J. Uttaro, J. Drake, and W. Henderickx, “Bgp mpls-based ethernet vpn,” Tech.
Rep., February 2015.
[40] S. Bidkar, A. Gumaste, and A. Somani, “A scalable framework for segment routing in service provider networks: The
omnipresent ethernet approach,” in 2014 IEEE 15th International Conference on High Performance Switching and Routing
(HPSR). IEEE, 2014, pp. 76–83.
[41] A. Sgambelluri, F. Paolucci, A. Giorgetti, F. Cugini, and P. Castoldi, “Experimental demonstration of segment routing,”
Journal of Lightwave Technology, vol. 34, no. 1, pp. 205–212, 2016.
43
[42] R. Wojcik, J. Domzal, Z. Dulinski, G. Rzym, A. Kamisinski, P. Gawlowicz, P. Jurkiewicz, J. Rzkasa, R. Stankiewicz,
and K. Wajda, “A survey on methods to provide interdomain multipath transmissions,” Computer Networks, vol. 108, pp.
233–259, 2016.
[43] C. Filsfils, S. Previdi, E. Aries, and D. Afanasieve, “Segment routing centralized bgp egress peer engineering,” IETF Spring
Working Group draft-ietf-spring-segment-routing-central-epe-05, 2017.
[44] D. Lebrun, S. Previdi, C. Filsfils, and O. Bonaventure, “Design and implementation of ipv6 segment routing,” Web
site.[Online]. Available: http://www. segment-routing. org, 2016.
[45] D. Lebrun, “A linux kernel implementation of segment routing with ipv6,” in Computer Communications Workshops
(INFOCOM WKSHPS), 2016 IEEE Conference on. IEEE, 2016, pp. 1019–1020.
[46] S. Previdi, M. Horneffer, S. Litkowski, C. Filsfils, B. Decraene, and R. Shakir, “Source packet routing in networking
(spring) problem statement and requirements,” IETF RFC 7855, 2016.
[47] C. Villamizar, L. Yong, D. McDysan, A. Malis, and S. Ning, “Requirements for advanced multipath in mpls networks,”
IETF RFC 7226, 2014.
[48] F. Lazzeri, G. Bruno, J. Nijhof, A. Giorgetti, and P. Castoldi, “Efficient label encoding in segment-routing enabled optical
networks,” in Optical Network Design and Modeling (ONDM), 2015 International Conference on. IEEE, 2015, pp. 34–38.
[49] A. Cianfrani, M. Listanti, and M. Polverini, “Translating traffic engineering outcome into segment routing paths: The
encoding problem,” in Computer Communications Workshops (INFOCOM WKSHPS), 2016 IEEE Conference on. IEEE,
2016, pp. 245–250.
[50] R. Guedrez, O. Dugeon, S. Lahoud, and G. Texier, “Label encoding algorithm for mpls segment routing,” in Network
Computing and Applications (NCA), 2016 IEEE 15th International Symposium on. IEEE, 2016, pp. 113–117.
[51] A. Giorgetti, P. Castoldi, F. Cugini, J. Nijhof, F. Lazzeri, and G. Bruno, “Path encoding in segment routing,” in 2015 IEEE
Global Communications Conference (GLOBECOM). IEEE, 2015, pp. 1–6.
[52] C. Filsfils, S. Sivabalan, D. Yoyer, M. Nanduri, M. Bogdanov, Horneffer et al., “Segment routing policy for traffic
engineering,” IETF Spring Working Group draft-filsfils-spring-segment-routing-policy-00.txt (work in progress), 2017.
[53] E. Moreno, A. Beghelli, and F. Cugini, “Traffic engineering in segment routing networks,” Computer Networks, vol. 114,
pp. 23–31, 2017.
[54] A. Mendiola, J. Astorga, E. Jacob, and M. Higuero, “A survey on the contributions of software-defined networking to
traffic engineering,” IEEE Communications Surveys & Tutorials, pp. 918–953, 2016.
[55] R. Bhatia, F. Hao, M. Kodialam, and T. Lakshman, “Optimized network traffic engineering using segment routing,” in
2015 IEEE Conference on Computer Communications (INFOCOM). IEEE, 2015, pp. 657–665.
[56] R. Hartert, S. Vissicchio, P. Schaus, O. Bonaventure, C. Filsfils, T. Telkamp, and P. Francois, “A declarative and expressive
approach to control forwarding paths in carrier-grade networks,” in ACM SIGCOMM Computer Communication Review,
vol. 45, no. 4. ACM, 2015, pp. 15–28.
[57] R. Hartert, P. Schaus, S. Vissicchio, and O. Bonaventure, “Solving segment routing problems with hybrid constraint
programming techniques,” in International Conference on Principles and Practice of Constraint Programming. Springer,
2015, pp. 592–608.
[58] G. Trimponias, Y. Xiao, H. Xu, X. Wu, and Y. Geng, “On traffic engineering with segment routing in sdn based wans,”
arXiv preprint arXiv:1703.05907, 2017.
[59] S. Gay, R. Hartert, and S. Vissicchio, “Expect the unexpected: Sub-second optimization for segment routing,” IEEE
Conference on Computer Communications (INFOCOM), pp. 1–9, 05 2017.
[60] S. Salsano, L. Veltri, L. Davoli, P. L. Ventre, and G. Siracusano, “Pmsr-poor man’s segment routing, a minimalistic approach
to segment routing and a traffic engineering use case,” arXiv preprint arXiv:1512.05281, 2015.
44
[61] B. Addis, A. Capone, G. Carello, L. G. Gianoli, and B. Sansò, “Energy management in communication networks: a journey
through modelling and optimization glasses,” arXiv preprint arXiv:1507.02636, 2015.
[62] R. Carpa, O. Glück, and L. Lefevre, “Segment routing based traffic engineering for energy efficient backbone networks,”
in 2014 IEEE International Conference on Advanced Networks and Telecommuncations Systems (ANTS). IEEE, 2014,
pp. 1–6.
[63] R. Carpa, O. Gluck, L. Lefevre, and J.-C. Mignot, “Improving the energy efficiency of software-defined backbone networks,”
Photonic Network Communications, vol. 30, no. 3, pp. 337–347, 2015.
[64] M. D. de Assunção, R. Carpa, L. Lefèvre, and O. Glück, “On designing sdn services for energy-aware traffic engineering,”
in Testbeds and Research Infrastructures for the Development of Networks and Communities. Springer, 2016, pp. 14–23.
[65] L. Davoli, L. Veltri, P. L. Ventre, G. Siracusano, and S. Salsano, “Traffic engineering with segment routing: Sdn-based
architectural design and open source implementation,” in 2015 Fourth European Workshop on Software Defined Networks.
IEEE, 2015, pp. 111–112.
[66] C. Thaenchaikun, G. Jakllari, B. Paillassa, and W. Panichpattanakul, “Mitigate the load sharing of segment routing for
sdn green traffic engineering,” in Intelligent Signal Processing and Communication Systems (ISPACS), 2016 International
Symposium on. IEEE, 2016, pp. 1–6.
[67] M.-C. Lee and J.-P. Sheu, “An efficient routing algorithm based on segment routing in software-defined networking,”
Computer Networks, vol. 103, pp. 44–55, 2016.
[68] F. Hao, M. Kodialam, and T. Lakshman, “Optimizing restoration with segment routing,” in Computer Communications,
IEEE INFOCOM 2016-The 35th Annual IEEE International Conference on. IEEE, 2016, pp. 1–9.
[69] A. Giorgetti, A. Sgambelluri, F. Paolucci, F. Cugini, and P. Castoldi, “Demonstration of dynamic restoration in segment
routing multi-layer sdn networks,” in Optical Fiber Communication Conference. Optical Society of America, 2016, pp.
Th4G–4.
[70] A. Giorgetti, A. Sgambelluri, F. Paolucci, F. Cugini, and P. Castoldi, “Segment routing for effective recovery and multi-
domain traffic engineering,” vol. 9, no. 2, 2017, pp. A223–A232.
[71] F. Aubry, D. Lebrun, Y. Deville, and O. Bonaventure, “Traffic duplication through segmentable disjoint paths,” in IFIP
Networking Conference (IFIP Networking), 2015. IEEE, 2015, pp. 1–9.
[72] F. Aubry, Y. Lebrun, D.and Deville, and O. Bonaventure, “Traffic dispersion through segmentable disjoint paths,” Web
site.[Online]. Available: https://www.info.ucl.ac.be/ yde/Papers/ifip2015.pdf.
[73] Halpern, Joel, and C. Pignataro, “Service function chaining (sfc) architecture,” Tech. Rep., 2015.
[74] N. Houtain and T. Gerondal, “Service function chaining with segment routing,” 2016.
[75] F. Paolucci, A. Giorgetti, F. Cugini, and P. Castoldi, “Service chaining in multi-layer networks using segment routing and
extended bgp flowspec,” in Optical Fiber Communication Conference. Optical Society of America, 2017, pp. W4J–3.
[76] A. AbdelSalam, F. Clad, C. Filsfils, S. Salsano, G. Siracusano, and L. Veltri, “Implementation of virtual network function
chaining through segment routing in a linux-based nfv infrastructure,” arXiv preprint arXiv:1702.05157, 2017.
[77] D. Bhamare, R. Jain, M. Samaka, and A. Erbad, “A survey on service function chaining,” Journal of Network and Computer
Applications, vol. 75, pp. 138–155, 2016.
[78] R. Krishnan, L. Yong, A. Ghanwani, N. So, and B. Khasnabish, “Mechanisms for optimizing link aggregation group (lag)
and equal-cost multipath (ecmp) component link utilization in networks,” Tech. Rep., January 2015.
[79] F. Aubry, D. Lebrun, S. Vissicchio, M. T. Khong, Y. Deville, O. Bonaventure et al., “Scmon: Leveraging segment routing
to improve network monitoring,” in IEEE INFOCOM, 2016, pp. 1–9.
[80] C. Filsfils, S. Previdi, J. Mitchell, and P. Aries, E.and Lapukhov, “Bgp-prefix segment in large-scale data centers,” in
Network Working Group/ Internet-Draft, no. 04. Cisco Systems, Unaffiliated, Juniper Networks, Facebook, 2017.
45
[81] D. King and A. Farrel, “The application of the path computation element architecture to the determination of a sequence
of domains in mpls and gmpls,” IETF RFC 6805, 2012.
[82] C. Filsfils, D. Cai, S. Previdi, W. Henderickx, D. Cooper, T. Laberge, S. Lin, B. Decraene, Orange, L. Jalil, J. Tantsura,
and R. Shakir, “Interconnecting millions of endpoints with segment routing,” IETF Spring Working Group draft-filsfils-
spring-large-scale-interconnect-05, 2017.
[83] R. Guerzoni, D. Perez-Caparros, P. Monti, G. Giuliani, J. Melian, and G. Biczók, “Multi-domain orchestration and
management of software defined infrastructures: a bottom-up approach,” IEEE European Conference on Networks and
Commnications, 2016: 1-6.
[84] F. Paolucci, V. Uceda, A. Sgambelluri, F. Cugini, O. G. De Dios, V. Lopez, L. Contreras, P. Monti, P. Iovanna, F. Ubaldi
et al., “Interoperable multi-domain delay-aware provisioning using segment routing monitoring and bgp-ls advertisement,”
in ECOC 2016; 42nd European Conference on Optical Communication; Proceedings of. VDE, 2016, pp. 1–3.
[85] X. Xu, S. Bryant, R. Raszuk, U. Chunduri, L. Contreras, L. Jalil, and H. Assarpour, “Unified source routing instruction
using mpls label stack,” IETF MPLS Working Group draft-xu-mpls-unified-source-routing-instruction-00 (work in progress),
2017.
[86] Z. AlSaeed, I. Ahmad, and I. Hussain, “Multicasting in software defined networks: A comprehensive survey,” Journal of
Network and Computer Applications, vol. 104, 2018.
[87] J.-P. Sheu and Y.-C. Chen, “A scalable and bandwidth-efficient multicast algorithm based on segment routing in software-
defined networking,” in Communications (ICC), 2017 IEEE International Conference on. IEEE, 2017, pp. 1–6.
[88] C. Kim, P. Bhide, E. Doe, H. Holbrook, A. Ghanwani, D. Daly, M. Hira, and B. Davie, “In-band network telemetry (int),”
P4 consortium, 2015.
[89] F. Brockners et al., “Requirements for in-situ oam,” IETF Network Working Group draft-brockners-inband-oam-
requirements-03 (work in progress), 2017.
[90] E. Amaldi, B. Fortz, and C. Iuliano, “On finding a minimum weight cycle basis with cycles of bounded length.” in CTW,
2010, pp. 5–8.
[91] D. S. Hochbaum and E. V. Olinick, “The bounded cycle-cover problem,” INFORMS Journal on Computing, vol. 13, no. 2,
pp. 104–119, 2001.
[92] X. Li, P. Djukic, and H. Zhang, “Zoning for hierarchical network optimization in software defined networks,” in Network
Operations and Management Symposium (NOMS), 2014 IEEE. IEEE, 2014, pp. 1–8.
[93] N. Ogino, T. Kitahara, S. Arakawa, G. Hasegawa, and M. Murata, “Decentralized boolean network tomography based on
network partitioning,” in Network Operations and Management Symposium (NOMS), 2016 IEEE/IFIP. IEEE, 2016, pp.
162–170.
[94] J. Blendin, D. Herrmann, M. Wichtlhuber, M. Gunkel, F. Wissel, and D. Hausheer, “Enabling efficient multi-layer repair
in elastic optical networks by gradually superimposing sdn,” in Network and Service Management (CNSM), 2016 12th
International Conference on. IEEE, 2016, pp. 118–126.
[95] M. Anand, R. Subrahmaniam, S. Roy, and R. Valiveti, “Extending segment routing into optical networks,” in Optical Fiber
Communication Conference. Optical Society of America, 2017, pp. Th1I–3.
[96] P. Francois, C. Filsfils, A. Bashandy, and S. Litkowski, “Loop avoidance using segment routing,” IETF Spring Working
Group draft-francois-rtgwg-segment-routing-uloop-01, 2016.

Abdullah 2018

Uploaded by

Copyright:

Available Formats

Abdullah 2018

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Abdullah 2018

Uploaded by

Copyright:

Available Formats

This article has been accepted for publication in a future issue of this journal, but has not been

Segment Routing in Software Defined

Department of Computer Engineering∗ † , Kuwait University, State of Kuwait

TABLE I: List of acronyms

Fig. 1: Illustration of the same SRGB allocation on all SR nodes

set of unidirectional adjacencies is referred to as an Adjacency Segment [18]. An IGP

Fig. 2: Illustration of segment operations

Fig. 3: IGP segment types

to as the Prefix SID. An illustration of an IGP prefix segment is given in Figure

Fig. 4: Illustration of an IGP Adjacency Segment

Fig. 5: Illustration of IGP Prefix/Node Segments

through the network as illustrated in Figure 6. In this case, R1 sends a packet to R6

Fig. 6: Illustration of combining Prefix-SIDs and Adj-SIDs for an explicit path

Fig. 7: Illustration of an IGP Anycast Segment

Fig. 8: Illustration of IGP Anycast Segment providing High Availability

III. IGP S EGMENTS SR U SE C ASES

This section describes SR use cases enabled by the IGP segments.

Fig. 9: SR based simplified transport for MPLS VPN services

A. Simple Transport Paths for L2VPN and L3VPN Services

B. Traffic Engineered Transport Paths for L2VPN and L3VPN Services

C. Fault Resilient SR Paths for L2VPN and L3VPN Services

Fig. 11: An illustration of SR path protection scheme

D. Data Plane Monitoring of SR Paths for L2VPN and L3VPN Services

Fig. 12: An illustration of SR path data plane monitoring

IV. SR PATH E NCODING I MPLICATIONS

TABLE II: Comparison of label encoding algorithm in segment routing

References Performance metric Constraints Optimization strategy

As described so far, applying SR in regular networks can achieve improvements at different

A. Traffic Engineering (TE)

B. Recovery from Failures

TABLE III: Comparison of TE techniques in segment routing

References TE Objectives Constraints Optimization Strategy

C. Traffic Duplication for Protection

destination. The algorithm is implemented either in a centralized controller or in a distributed

D. Service Function Chaining (SFC)

E. SR based Network Monitoring

Fig. 15: An illustration of SFC realization using SR

F. SR in Large Scale Data Centers

VI. C HALLENGES AND F UTURE W ORK

You might also like

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.