464 IEEE COMMUNICATIONS SURVEYS & TUTORIALS, VOL. 21, NO.
1, FIRST QUARTER 2019
Segment Routing in Software Defined
Networks: A Survey
Zahraa N. Abdullah, Imtiaz Ahmad , and Iftekhar Hussain
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. The emerg-
ing cloud services require strict service level agreements 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 incom-
ing packet along a performance engineered path represented as
an ordered list of instructions called segment list. This is encoded
as a multiprotocol label switching label stack or an IPv6 address
list in the packet header. This paper provides a comprehensive
review of the novel SR technology by describing its architec-
ture, operations, and key applications to date. SR paradigm can
be effectively applied to a wide range of network applications,
such as traffic engineering, network resiliency, network monitor-
ing, and service function chaining, 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.
Index Terms—Segment routing (SR), software defined
networks (SDN), controller, control plane, data plane, traffic
engineering (TE), network monitoring.
I. I NTRODUCTION
RADITIONAL network architectures are unsuitable to
T meet the cloud-based services requirements of mod-
ern data centers and carriers. These limitations arise due
to network infrastructure inflexibility (e.g., tight coupling
between control and data planes leading to a specific vendor
lock-in) and lack of automation and programmability con-
tributing 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 hierar-
chical 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
Manuscript received May 9, 2017; revised October 7, 2017, March 10, 2018,
and June 9, 2018; accepted September 6, 2018. Date of publication September
13, 2018; date of current version February 22, 2019. (Corresponding author:
Imtiaz Ahmad.)
Z. N. Abdullah and I. Ahmad are with the Department of Computer
Engineering, Kuwait University, Kuwait City 13060, Kuwait (e-mail:
znaabdullah@gmail.com; imtiaz.ahmad@ku.edu.kw).
I. Hussain is with the System Architecture Group, Infinera Corporation,
Sunnyvale, CA 94089 USA (e-mail: ihussain@infinera.com).
Digital Object Identifier 10.1109/COMST.2018.2869754
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.
Authorized licensed use limited to: CHONNAM NATIONAL UNIVERSITY. Downloaded on April 01,2020 at 09:39:45 UTC from IEEE Xplore. Restrictions apply.
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 provi-
sion network resources (e.g., bandwidth) to meet Service Level
Agreements (SLAs) and monitor network performance.
The promising Software Defined Networking (SDN) tech-
nology is radically transforming the network architecture of
data centers, network overlays, and carrier networks to over-
come 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 infrastruc-
ture layer from the applications through well-defined north-
bound and southbound Application Programming Interfaces
(APIs) [2]–[8]. For instance, applications may gather network
intelligence information from the controller using Web-based
Representational State Transfer (REST) APIs, run its algo-
rithms, 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 pro-
tocols 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 peer-
ing 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, pro-
grammability, 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
ABDULLAH et al.: SR IN SDN: SURVEY
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 archi-
tecture 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 mer-
chant 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 promis-
ing 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 granu-
larity 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 conges-
tion 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 transmis-
sion 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] and [15] may help
in reducing the TCAM entries and controller-switch interac-
tions, 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
Authorized licensed use limited to: CHONNAM NATIONAL UNIVERSITY. Downloaded on April 01,2020 at 09:39:45 UTC from IEEE Xplore. Restrictions apply.
465
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 tech-
nologies 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), pro-
grammability (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 manageabil-
ity (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
466 IEEE COMMUNICATIONS SURVEYS & TUTORIALS, VOL. 21, NO. 1, FIRST QUARTER 2019
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 seg-
ment) to forward the packet to the next hop according to the
given instruction (e.g., forward packet to shortest path to desti-
nation 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 mecha-
nisms 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 sup-
ported 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 des-
tination, 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.
Authorized licensed use limited to: CHONNAM NATIONAL UNIVERSITY. Downloaded on April 01,2020 at 09:39:45 UTC from IEEE Xplore. Restrictions apply.
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 outper-
forms 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 concate-
nating 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 frame-
work that is implemented using an SR supported Carrier
Ethernet as Software Defined-Carrier Ethernet Switch Routers
(SD-CESRs). Carrier Ethernet is a properly standardized solu-
tion 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].
Cai et al. [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 ser-
vices (Residential, Business, Mobile Backhaul) with simplic-
ity, programmability, and guaranteed service level agreements
over a programmable network infrastructure. Another generic
work has been proposed in [40] where SR enabled trans-
port paradigm is implemented specifically in IP/MPLS Carrier
Ethernet technology. This work fully leverages the SR ben-
efits 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 con-
troller. Both implementation scenarios have shown a successful
dynamic traffic rerouting with no packet loss while eliminating
the need for complex signaling protocols.
ABDULLAH et al.: SR IN SDN: SURVEY 467

TABLE I
Despite the attention and wide industrial acceptance the SR L IST OF ACRONYMS
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 incom-
ing 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, for-
ward 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 con-
tains the segment list along with a pointer that indicates
the active segment to be processed by the current hold-
ing device, where this pointer points to the next segment
when the current one is executed [17], [18]. Each seg-
ment 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 and thus must be unique within its domain. In
MPLS instantiation of the SR, each SR node maintains originating node advertises a label range [100, 199] and
a set of local labels reserved for global segments in the an index = 1, the receiving node determines the global
SR Global Block (SRGB). Global segments are adver- segment’s label value to be 101 (i.e., SRGB=[100,199],
tised as a label range and an index. For example, if an index range = 0 to 199, index=0 means label=100,

Authorized licensed use limited to: CHONNAM NATIONAL UNIVERSITY. Downloaded on April 01,2020 at 09:39:45 UTC from IEEE Xplore. Restrictions apply.
468
Fig. 1. Illustration of the same SRGB allocation on all SR nodes.
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 oper-
ations 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 (instruc-
tion 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 segmenta-
tion operations and equivalent MPLS label operations.
In SR with the MPLS data plane, several types of seg-
ments 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 rep-
resents a piece of information that an SR-capable IGP
node advertises such as attached prefixes and adjacen-
cies. The SR architecture can be applied not only to IGP
segments, but also to other forms of segments (e.g., seg-
ments 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.
Authorized licensed use limited to: CHONNAM NATIONAL UNIVERSITY. Downloaded on April 01,2020 at 09:39:45 UTC from IEEE Xplore. Restrictions apply.
IEEE COMMUNICATIONS SURVEYS & TUTORIALS, VOL. 21, NO. 1, FIRST QUARTER 2019
a) IGP Adjacency Segment: An IGP segment attached
to a unidirectional adjacency or set of unidirec-
tional 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 fea-
ture 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 repre-
sents a global prefix (unless advertised otherwise)
with the SR IGP topology and denotes an instruc-
tion 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 to as the Prefix SID.
An illustration of an IGP prefix segment is given
in Figure 5. Assume operator allocates an IP pre-
fix 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 adver-
tises the IGP SID 1006 within the IGP domain. R1
ABDULLAH et al.: SR IN SDN: SURVEY
Fig. 2. Illustration of segment operations.
Fig. 3. IGP segment types.
sends a packet to a prefix 192.0.1.6/32 attached to
R6 by pushing the segment list 1006 on the packet
header. Since the IGP prefix has a global seman-
tic 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 loop-
back 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
Authorized licensed use limited to: CHONNAM NATIONAL UNIVERSITY. Downloaded on April 01,2020 at 09:39:45 UTC from IEEE Xplore. Restrictions apply.
469
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 advertis-
ing 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
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.
470
Fig. 4. Illustration of an IGP Adjacency Segment.
Fig. 5. Illustration of IGP Prefix/Node Segments.
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
Authorized licensed use limited to: CHONNAM NATIONAL UNIVERSITY. Downloaded on April 01,2020 at 09:39:45 UTC from IEEE Xplore. Restrictions apply.
IEEE COMMUNICATIONS SURVEYS & TUTORIALS, VOL. 21, NO. 1, FIRST QUARTER 2019
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 seg-
ment 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 pre-
fix 192.0.1.3 is reachable from R2 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,
ABDULLAH et al.: SR IN SDN: SURVEY
Fig. 6. Illustration of combining Prefix-SIDs and Adj-SIDs for an explicit path.
Fig. 7. Illustration of an IGP Anycast Segment.
and traffic engineering using macro TE expressions
(i.e., coarse TE policies).
e) Service Segment: A Service Segment is a local seg-
ment that can be used to represent a particular
service treatment to be applied to a packet. By
combining IGP segments with the service seg-
ments (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
Authorized licensed use limited to: CHONNAM NATIONAL UNIVERSITY. Downloaded on April 01,2020 at 09:39:45 UTC from IEEE Xplore. Restrictions apply.
471
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
472
Fig. 8. Illustration of IGP Anycast Segment providing High Availability.
to advertise the various IGP SIDs. These IGP exten-
sions 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 pre-
fix 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 seg-
ments are LDP LSP, RSVP-TE and BGP LSP. BGP
segments allow the traffic to use any path that is differ-
ent 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 scenar-
ios. 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
Authorized licensed use limited to: CHONNAM NATIONAL UNIVERSITY. Downloaded on April 01,2020 at 09:39:45 UTC from IEEE Xplore. Restrictions apply.
IEEE COMMUNICATIONS SURVEYS & TUTORIALS, VOL. 21, NO. 1, FIRST QUARTER 2019
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.
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 bene-
fits 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 opera-
tor only needs to configure node segment per PE and the SR
IGP control-plane automatically setup the tunnels) (b) ECMP-
aware tunnels (see [46] and [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 effi-
cient 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, enter-
prise, and data center network architectures [46], [47]. In
these network architectures, one of the key network efficiency
ABDULLAH et al.: SR IN SDN: SURVEY
Fig. 9. SR based simplified transport for MPLS VPN services.
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
carry their traffic. In SR, IGP Segments are the basic building
blocks which can be combined to steer packets along a traf-
fic engineered path. SR provides a mechanism by which the
data plane of a MPLS network can be programmed to real-
ize 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 com-
pute 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 con-
straints such that the path must avoid PE1-P2 link and must
use P3-P4 link. SDN controller invokes the PCE to process this
Authorized licensed use limited to: CHONNAM NATIONAL UNIVERSITY. Downloaded on April 01,2020 at 09:39:45 UTC from IEEE Xplore. Restrictions apply.
473
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 local protection or Fast
Reroute (FRR) technique. In contrast, when protection is per-
formed 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 dis-
joint 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 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 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
474
Fig. 10. Illustration of an SR-TE tunnel set up using the SDN controller.
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 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 real-
ize 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 con-
gestion. 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 seg-
ment list computation to address the above issues by joint
Authorized licensed use limited to: CHONNAM NATIONAL UNIVERSITY. Downloaded on April 01,2020 at 09:39:45 UTC from IEEE Xplore. Restrictions apply.
IEEE COMMUNICATIONS SURVEYS & TUTORIALS, VOL. 21, NO. 1, FIRST QUARTER 2019
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, Lazzeri et al. [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 dur-
ing the initialization phase or after topology realignment. The
paths are computed with IGP metrics and the SIDs are adver-
tised 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 paths are more granu-
lar. The resulting paths are the concatenation of physical and
ABDULLAH et al.: SR IN SDN: SURVEY
Fig. 11. An illustration of SR path protection scheme.
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 encod-
ing 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 formula-
tion 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 cur-
rently 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
Authorized licensed use limited to: CHONNAM NATIONAL UNIVERSITY. Downloaded on April 01,2020 at 09:39:45 UTC from IEEE Xplore. Restrictions apply.
475
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 destina-
tion 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 sum-
mary 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 num-
ber of segments that needs to be imposed by the source node
as illustrated in Figure 14.
V. SR A PPLICATIONS
As described so far, applying SR in regular networks can
achieve improvements at different levels. This is due to the
476 IEEE COMMUNICATIONS SURVEYS & TUTORIALS, VOL. 21, NO. 1, FIRST QUARTER 2019

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

Fig. 13. An illustration of segment list depth for two paths over a network topology.

rich set of capabilities that the SR enables such as traffic engi-
neering, packet restoration and duplication, service function
chaining, network monitoring, application in data centers and
multi-domain routing as discussed in the following sections.
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 con-
sists of an ordered segment list containing one or more SIDs

Authorized licensed use limited to: CHONNAM NATIONAL UNIVERSITY. Downloaded on April 01,2020 at 09:39:45 UTC from IEEE Xplore. Restrictions apply.
ABDULLAH et al.: SR IN SDN: SURVEY
Fig. 14. An illustration of BSID usage for reducing the segment list depth [52].
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 cen-
tralized 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 split-
ting 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.
Authorized licensed use limited to: CHONNAM NATIONAL UNIVERSITY. Downloaded on April 01,2020 at 09:39:45 UTC from IEEE Xplore. Restrictions apply.
477
•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, since it results in less
packet loss and minimized end-to-end delay. The work intro-
duced 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 traf-
fic 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 dis-
tributed 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 con-
tains 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 program-
ming framework to compute forwarding paths for TE in SR.
478
TABLE II
C OMPARISON OF L ABEL E NCODING A LGORITHM IN S EGMENT ROUTING
Trimponias et al. [58] proposed a polynomial time heuristic
by selecting few important nodes as middle points for all traf-
fic. 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]. Salsano et al. [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 compu-
tations in terms of the number of segments that 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 communi-
cations. Moreover, the work done in [49] have conducted a
proper formulation of the segment list in path encoding lit-
erature, 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 minimiz-
ing the energy consumption can be performed by adjusting
link weights and by diverting the traffic from the sleeping
nodes [61]. An energy efficient TE solution was introduced
Authorized licensed use limited to: CHONNAM NATIONAL UNIVERSITY. Downloaded on April 01,2020 at 09:39:45 UTC from IEEE Xplore. Restrictions apply.
IEEE COMMUNICATIONS SURVEYS & TUTORIALS, VOL. 21, NO. 1, FIRST QUARTER 2019
by Carpa et al. [62] by selectively turning on/off any sub-
set 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 conver-
gence 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 opin-
ions 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 applica-
tion of SDN with a centralized view of the network topology
allowed to simplify and improve efficiency of the TE solution.
De Assunção et al. [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 conges-
tion 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 simula-
tion, and it was shown that the application of SR in SDNs
enhanced the efficiency of TE [64]. Davoli et al. [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 band-
width, computation, and buffer space. The efficient utilization
of network resources can lead to serving higher number of
traffic demands without increasing the network infrastructure
cost [54]. Moreover, this objective impacts other aspects such
as network congestion. The work in [66] addresses the appli-
cation 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.
ABDULLAH et al.: SR IN SDN: SURVEY
TABLE III
C OMPARISON OF TE T ECHNIQUES IN S EGMENT ROUTING
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 corre-
sponding 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, Moreno et al. [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 effi-
cient TE. Lee and Sheu [67] exploited SR in SDN in order to
optimize network performance and network resource utiliza-
tion 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 controller in SR helps exploit its potentials by choosing
segments according to the traffic pattern. The choice of seg-
ments 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
Authorized licensed use limited to: CHONNAM NATIONAL UNIVERSITY. Downloaded on April 01,2020 at 09:39:45 UTC from IEEE Xplore. Restrictions apply.
479
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] and [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 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 fail-
ure, 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 destina-
tion 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.
480
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. Aubry et al. [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 dis-
joint 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 destination. The algo-
rithm 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 sensi-
tive 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 intro-
duces 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 con-
straints 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
Authorized licensed use limited to: CHONNAM NATIONAL UNIVERSITY. Downloaded on April 01,2020 at 09:39:45 UTC from IEEE Xplore. Restrictions apply.
IEEE COMMUNICATIONS SURVEYS & TUTORIALS, VOL. 21, NO. 1, FIRST QUARTER 2019
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 real-
ity 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. 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 dif-
ferent 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 steer-
ing multiple MicroFlows with the same set of service functions
onto a single SR path at the network edge at a MicroFlow level
granularity. Paolucci et al. [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 technol-
ogy 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 pack-
ets 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 fol-
lowing challenges for network monitoring. First, it is hard to
monitor parallel links (or paths) at per link (or per path) gran-
ularity. 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,
ABDULLAH et al.: SR IN SDN: SURVEY
Fig. 15. An illustration of SFC realization using SR.
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 send-
ing/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 tun-
nels 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 enables a centralized monitoring system to per-
form a continuity check along all Label Switched Paths of
the SR domain [26]. Aubry et al. [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 mon-
itoring 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
Authorized licensed use limited to: CHONNAM NATIONAL UNIVERSITY. Downloaded on April 01,2020 at 09:39:45 UTC from IEEE Xplore. Restrictions apply.
481
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. 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 hard-
ware equipment to provide computer, storage, and networking
resources. Large scale data center networks typically deploy
multi-rooted CLOS topologies with a large number of par-
allel 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
482
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 illus-
trated in Figure 16. In a multi-domain scenario, the compu-
tation 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 main-
tains an abstract view of domain topology map in which child
PCEs are represented as vertices in the topology and their
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 can-
didate 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] demon-
strates 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 method-
ology to exchange SID information in multi-domain scenarios.
The hierarchal architecture enables the orchestrator to com-
pute 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 avail-
ability based on only SIDs to ensure the confidentiality of
intra-domain topology related information. After capturing the
topologies of all domains, the orchestrator runs specific algo-
rithms to determine the border nodes and the intra-domain
Authorized licensed use limited to: CHONNAM NATIONAL UNIVERSITY. Downloaded on April 01,2020 at 09:39:45 UTC from IEEE Xplore. Restrictions apply.
IEEE COMMUNICATIONS SURVEYS & TUTORIALS, VOL. 21, NO. 1, FIRST QUARTER 2019
connectivity to calculate the best feasible paths using prefix of
Adj-SIDs. This implementation provided flexibility and scal-
ability 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 orches-
tration. This approach has fulfilled the industry requirements
and the standard associations such as NGMN, ITU-T FG
IMT-2020, and IMT-2020(5G). Paolucci et al. [84] have also
conducted a novel network monitoring system based on the
multi-domain orchestration. Their work leveraged the SR tech-
nique 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 appli-
cations. 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 degra-
dation 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 appli-
cability in emerging cloud scale applications environment
such as IoT. SDN provides useful features to achieve profi-
cient 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 information in the packet header without requir-
ing 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
ABDULLAH et al.: SR IN SDN: SURVEY
Fig. 16. An illustration of end-to-end SR Deployment in intra and inter-DC use cases.
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 consid-
ered. The bounded cycles problem is an NP-complete problem
that was addressed in details in [90] and [91]. This creates
an opportunity to develop better heuristic approaches which
can consider tradeoff between the solution quality and run-
ning 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 exten-
sions 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 infras-
tructure cost, improved network efficiency) network solution.
Authorized licensed use limited to: CHONNAM NATIONAL UNIVERSITY. Downloaded on April 01,2020 at 09:39:45 UTC from IEEE Xplore. Restrictions apply.
483
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 plays a
major role in the deployment of IoT [77], where it should pro-
vide interoperability among the large number of communicated
heterogeneous sensory devices in IoT paradigm.
VII. C ONCLUSION
The phenomenal growth of Internet traffic and emerg-
ing applications demand high capacity and high performance
networks, which poses new challenges regarding network man-
ageability 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 seg-
ment 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
484 IEEE COMMUNICATIONS SURVEYS & TUTORIALS, VOL. 21, NO. 1, FIRST QUARTER 2019
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 minor-
ity 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 comprehensive survey that cov-
ers 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 effec-
tively 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 pro-
tection, service function chaining, network monitoring, data
centers and service provider networks. For these applications,
SR showed better performance as compared with the tradi-
tional routing schemes with respect to performance metrics
such as link utilization, network resiliency, energy consump-
tion, and end-to-end delay. Finally, we discussed compelling
research challenges and open issues that could make the best
use of an innovative SR paradigm.
ACKNOWLEDGMENT
The authors would like to thank the anonymous reviewers
for their invaluable and thoughtful comments which definitely
improved overall quality of the manuscript.
R EFERENCES
[1] M. Al-Fares, A. Loukissas, and A. Vahdat, “A scalable, commodity data
center network architecture,” ACM SIGCOMM Comput. Commun. Rev.,
vol. 38, no. 4, pp. 63–74, 2008.
[2] Open Networking Foundation. Accessed: Dec. 2016. [Online]. Available:
https://www.opennetworking.org
[3] D. Kreutz et al., “Software-defined networking: A comprehensive
survey,” Proc. IEEE, vol. 103, no. 1, pp. 14–76, Jan. 2015.
[4] W. Xia, Y. Wen, C. H. Foh, D. Niyato, and H. Xie, “A survey on
software-defined networking,” IEEE Commun. Surveys Tuts., vol. 17,
no. 1, pp. 27–51, 1st Quart., 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 Commun.
Surveys Tuts., vol. 18, no. 4, pp. 2687–2712, 4th Quart., 2016.
[6] M. F. Tuysuz, Z. K. Ankarali, and D. Gözüpek, “A survey on energy
efficiency in software defined networks,” Comput. Netw., vol. 113,
pp. 188–204, Feb. 2017.
[7] W. Li, W. Meng, and L. F. Kwok, “A survey on OpenFlow-based
software defined networks: Security challenges and countermeasures,”
J. Netw. Comput. Appl., vol. 68, pp. 126–139, Jun. 2016.
[8] OpenDaylight: Open Source SDN Platform. Accessed: Dec. 2016.
[Online]. Available: https://www.opendaylight.org
[9] R. Enns, M. Bjorklund, J. Schoenwaelder, and A. Bierman, “Network
configuration protocol (NETCONF),” IETF, Fremont, CA, USA, RFC
6241, 2011.
Authorized licensed use limited to: CHONNAM NATIONAL UNIVERSITY. Downloaded on April 01,2020 at 09:39:45 UTC from IEEE Xplore. Restrictions apply.
[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,” Internet Eng. Task Force, Fremont, CA, USA, Rep. 7752,
2016.
[11] J. Le Roux, “Path computation element (PCE) communication protocol
(PCEP),” IETF, Fremont, CA, USA, RFC 5440, 2009.
[12] C.-Y. Hong et al., “Achieving high utilization with software-driven
WAN,” ACM SIGCOMM Comput. Commun. Rev., vol. 43, no. 4,
pp. 15–26, 2013.
[13] S. Jain et al., “B4: Experience with a globally-deployed software
defined WAN,” ACM SIGCOMM Comput. Commun. Rev., vol. 43, no. 4,
pp. 3–14, 2013.
[14] A. R. Curtis et al., “DevoFlow: Scaling flow management for high-
performance networks,” ACM SIGCOMM Comput. Commun. Rev.,
vol. 41, no. 4, pp. 254–265, 2011.
[15] A. S. Iyer, V. Mann, and N. R. Samineni, “SwitchReduce: Reducing
switch state and controller involvement in OpenFlow networks,”
in Proc. IEEE IFIP Netw. Conf., Brooklyn, NY, USA, 2013,
pp. 1–9.
[16] Spring-Open—An ONF Tag Project. Accessed: Feb. 2018. [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 Proc. IEEE Glob. Commun. Conf.
(GLOBECOM), San Diego, CA, USA, 2015, pp. 1–6.
[18] C. Filsfils et al., “Segment routing architecture,” IETF Netw. Work.
Group draft-ietf-springsegment-routing-09, Internet Eng. Task Force,
Fremont, CA, USA, 2016.
[19] C. Filsfils et al., “Segment routing with MPLS data plane,” IETF Spring
Working Group draft-ietf-spring-segment-routing-mpls-00, Internet Eng.
Task Force, Fremont, CA, USA, 2014.
[20] C. Filsfils et al., “IPv6 segment routing header (SRH),” IETF Spring
Working Group draft-ietf-6man-segment-routing-header-05, Internet
Eng. Task Force, Fremont, CA, USA, 2017.
[21] C. Filsfils et al., “OSPF extensions for segment routing,” IETF Spring
Working Group draft-ietf-ospf-segment-routing-extensions-10, Internet
Eng. Task Force, Fremont, CA, USA, 2016.
[22] S. Previdi et al., “IS-IS extensions for segment routing,” IETF Spring
Working Group draft ietf-isis-segment-routing-extensions-05, Internet
Eng. Task Force, Fremont, CA, USA, 2016.
[23] P. Psenak et al., “OSPFv3 extensions for segment routing,” IETF Spring
Working Group draft-ietf-ospf-ospfv3-segment-routing-extensions-07,
Internet Eng. Task Force, Fremont, CA, USA, 2016.
[24] S. Sivabalan et al., “PCEP extensions for segment routing,” IETF Spring
Working Group draft-ietf-pce-segment-routing-08, Internet Eng. Task
Force, Fremont, CA, USA, 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, Internet Eng. Task Force, Fremont, CA, USA,
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, Internet Eng. Task
Force, Fremont, CA, USA, 2017.
[27] N. Kumar et al., “Label switched path (LSP) ping/trace for segment
routing networks using MPLS dataplane,” IETF Spring Working Group
draft-ietf-mpls-spring-lsp-ping-02, Internet Eng. Task Force, Fremont,
CA, USA, 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, Internet Eng. Task Force, Fremont, CA, USA,
2017.
[29] A. Kos, “Segment routing principles and applications for SDN,”
M.S. thesis, Dipartimento di Elettronica, Informazione e Bioingegneria,
Politecnico Di Milano, Milan, Italy, 2016.
[30] Segment Routing Tutorials Available. Accessed: Sep. 2017. [Online].
Available: http://www.segment-routing.net/tutorials/
[31] C. Filsfils, K. Michielsen, and K. Talaulikar, Segment Routing Part I.
Scotts Valley, CA, USA: Create Space Independ. Publ. Platform, 2017.
[32] A. Farrel and R. Bonica, “Segment routing: Cutting through the hype
and finding the IETF’s innovative nugget of gold,” IETF J., vol. 13,
no. 1, pp. 5–9, Jul. 2017.
[33] C. Filsfils, “SRv6 network programming,” IETF Spring Working Group
draft-filsfils-spring-srv6-network-programming-00, Internet Eng. Task
Force, Fremont, CA, USA, 2017.
ABDULLAH et al.: SR IN SDN: SURVEY
[34] A. Giorgetti, A. Sgambelluri, F. Paolucci, and P. Castoldi, “Reliable
segment routing,” in Proc. 7th IEEE Int. Workshop Rel. Netw. Design
Model. (RNDM), Munich, Germany, 2015, pp. 181–185.
[35] N. Kukreja et al., “Demonstration of SDN-based orchestration for multi-
domain segment routing networks,” in Proc. 18th IEEE Int. Conf.
Transp. Opt. Netw. (ICTON), Trento, Italy, 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 Proc. IEEE Glob.
Commun. Conf. (GLOBECOM), Washington, DC, USA, 2016, pp. 1–6.
[37] S. Bidkar et al., “Field trial of a software defined network (SDN) using
carrier Ethernet and segment routing in a tier-1 provider,” in Proc. IEEE
Glob. Commun. Conf., Austin, TX, USA, 2014, pp. 2166–2172.
[38] D. Cai, A. Wielosz, and S. Wei, “Evolve carrier Ethernet architec-
ture with SDN and segment routing,” in Proc. 15th IEEE Int. Symp.
World Wireless Mobile Multimedia Netw. (WoWMoM), Sydney, NSW,
Australia, 2014, pp. 1–6.
[39] A. Sajassi et al., “BGP MPLS-based Ethernet VPN,” Internet Eng. Task
Force, Fremont, CA, USA, Rep. 7432, Feb. 2015.
[40] S. Bidkar, A. Gumaste, and A. Somani, “A scalable framework for seg-
ment routing in service provider networks: The omnipresent Ethernet
approach,” in Proc. IEEE 15th Int. Conf. High Perform. Switching
Routing (HPSR), Vancouver, BC, Canada, 2014, pp. 76–83.
[41] A. Sgambelluri, F. Paolucci, A. Giorgetti, F. Cugini, and P. Castoldi,
“Experimental demonstration of segment routing,” J. Lightw. Technol.,
vol. 34, no. 1, pp. 205–212, Jan. 1, 2016.
[42] R. Wójcik et al., “A survey on methods to provide interdomain
multipath transmissions,” Comput. Netw., vol. 108, pp. 233–259,
Oct. 2016.
[43] C. Filsfils, S. Previdi, E. Aries, and D. Afanasieve, “Segment rout-
ing centralized BGP egress peer engineering,” IETF Spring Working
Group draft-ietf-spring-segment-routing-central-epe-05, Internet Eng.
Task Force, Fremont, CA, USA, 2017.
[44] D. Lebrun, S. Previdi, C. Filsfils, and O. Bonaventure. (2016). Design
and Implementation of IPv6 Segment Routing. [Online]. Available:
http://www.segment-routing.org
[45] D. Lebrun, “A Linux kernel implementation of segment rout-
ing with IPv6,” in Proc. IEEE Conf. Comput. Commun.
Workshops (INFOCOM WKSHPS), San Francisco, CA, USA, 2016,
pp. 1019–1020.
[46] S. Previdi et al., “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,
Fremont, CA, USA, 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 Proc.
IEEE Int. Conf. Opt. Netw. Design Model. (ONDM), Pisa, Italy, 2015,
pp. 34–38.
[49] A. Cianfrani, M. Listanti, and M. Polverini, “Translating traffic engi-
neering outcome into segment routing paths: The encoding problem,” in
Proc. IEEE Conf. Comput. Commun. Workshops (INFOCOM WKSHPS),
San Francisco, CA, USA, 2016, pp. 245–250.
[50] R. Guedrez, O. Dugeon, S. Lahoud, and G. Texier, “Label encoding
algorithm for MPLS segment routing,” in Proc. 15th IEEE Int. Symp.
Netw. Comput. Appl. (NCA), Cambridge, MA, USA, 2016, pp. 113–117.
[51] A. Giorgetti et al., “Path encoding in segment routing,” in Proc. IEEE
Glob. Commun. Conf. (GLOBECOM), San Diego, CA, USA, 2015,
pp. 1–6.
[52] C. Filsfils et al., “Segment routing policy for traffic engineer-
ing,” IETF Spring Working Group draft-filsfils-spring-segment-routing-
policy-00.txt, Internet Eng. Task Force, Fremont, CA, USA, 2017.
[53] E. Moreno, A. Beghelli, and F. Cugini, “Traffic engineering in segment
routing networks,” Comput. Netw., vol. 114, pp. 23–31, Feb. 2017.
[54] A. Mendiola, J. Astorga, E. Jacob, and M. Higuero, “A survey on
the contributions of software-defined networking to traffic engineering,”
IEEE Commun. Surveys Tuts., vol. 19, no. 2, pp. 918–953, 2nd Quart.,
2017.
[55] R. Bhatia, F. Hao, M. Kodialam, and T. V. Lakshman, “Optimized
network traffic engineering using segment routing,” in Proc. IEEE Conf.
Comput. Commun. (INFOCOM), 2015, pp. 657–665.
[56] R. Hartert et al., “A declarative and expressive approach to control for-
warding paths in carrier-grade networks,” ACM SIGCOMM Comput.
Commun. Rev., vol. 45, no. 4, pp. 15–28, 2015.
[57] R. Hartert, P. Schaus, S. Vissicchio, and O. Bonaventure, “Solving
segment routing problems with hybrid constraint programming tech-
niques,” in Proc. Int. Conf. Principles Pract. Constraint Program., 2015,
pp. 592–608.
Authorized licensed use limited to: CHONNAM NATIONAL UNIVERSITY. Downloaded on April 01,2020 at 09:39:45 UTC from IEEE Xplore. Restrictions apply.
485
[58] G. Trimponias, Y. Xiao, H. Xu, X. Wu, and Y. Geng. (2017). On Traffic
Engineering With Segment Routing in SDN Based WANs. [Online].
Available: https://arxiv.org/abs/1703.05907
[59] S. Gay, R. Hartert, and S. Vissicchio, “Expect the unexpected: Sub-
second optimization for segment routing,” in Proc. IEEE Conf. Comput.
Commun. (INFOCOM), Atlanta, GA, USA, May 2017, pp. 1–9.
[60] S. Salsano, L. Veltri, L. Davoli, P. L. Ventre, and G. Siracusano.
(2015). PMSR—Poor Man’s Segment Routing, A Minimalistic Approach
to Segment Routing and A Traffic Engineering Use Case. [Online].
Available: https://arxiv.org/ftp/arxiv/papers/1512/1512.05281.pdf
[61] B. Addis, A. Capone, G. Carello, L. G. Gianoli, and B. Sansò.
(2015). Energy Management in Communication Networks: A Journey
Through Modelling and Optimization Glasses. [Online]. Available:
https://arxiv.org/pdf/1507.02636.pdf
[62] R. Carpa, O. Glück, and L. Lefevre, “Segment routing based traffic
engineering for energy efficient backbone networks,” in Proc. IEEE Int.
Conf. Adv. Netw. Telecommun. Syst. (ANTS), New Delhi, India, 2014,
pp. 1–6.
[63] R. Carpa, O. Gluck, L. Lefevre, and J.-C. Mignot, “Improving the
energy efficiency of software-defined backbone networks,” Photon.
Netw. Commun., vol. 30, no. 3, pp. 337–347, 2015.
[64] M. D. de Assunção, R. Carpa, L. Lefèvre, and O. Glück, “On design-
ing SDN services for energy-aware traffic engineering,” in Testbeds
and Research Infrastructures for the Development of Networks and
Communities. Cham, Switzerland: 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 Proc. 4th IEEE Eur. Workshop Softw.
Defined Netw., Bilbao, Spain, 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 Proc. IEEE Int. Symp. Intell. Signal Process. Commun.
Syst. (ISPACS), 2016, pp. 1–6.
[67] M.-C. Lee and J.-P. Sheu, “An efficient routing algorithm based on seg-
ment routing in software-defined networking,” Comput. Netw., vol. 103,
pp. 44–55, Jul. 2016.
[68] F. Hao, M. Kodialam, and T. Lakshman, “Optimizing restoration with
segment routing,” in Proc. 35th Annu. IEEE Int. Conf. Comput. Commun.
(IEEE INFOCOM), San Francisco, CA, USA, 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 Proc. Opt. Fiber Commun. Conf., 2016, pp. 1–3.
[70] A. Giorgetti, A. Sgambelluri, F. Paolucci, F. Cugini, and P. Castoldi,
“Segment routing for effective recovery and multi-domain traffic
engineering,” IEEE/OSA J. Opt. Commun. Netw., vol. 9, no. 2,
pp. A223–A232, Feb. 2017.
[71] F. Aubry, D. Lebrun, Y. Deville, and O. Bonaventure, “Traffic dupli-
cation through segmentable disjoint paths,” in Proc. IFIP Netw. Conf.
(IFIP Networking), Toulouse, France, 2015, pp. 1–9.
[72] F. Aubry, Y. Lebrun, Y. Deville, and O. Bonaventure. Accessed:
Sep. 2017. Traffic Dispersion Through Segmentable Disjoint Paths.
[Online]. Available: https://www.info.ucl.ac.be/yde/Papers/ifip2015.pdf
[73] J. Halpern and C. Pignataro, “Service function chaining (SFC) archi-
tecture,” Internet Eng. Task Force, Fremont, CA, USA, Rep. 7665,
2015.
[74] N. Houtain and T. Gerondal. (2016). Service Function
Chaining With Segment Routing. [Online]. Available:
http://hdl.handle.net/2078.1/thesis:4621
[75] F. Paolucci, A. Giorgetti, F. Cugini, and P. Castoldi, “Service chain-
ing in multi-layer networks using segment routing and extended BGP
FlowSpec,” in Proc. Opt. Fiber Commun. Conf., Los Angeles, CA, USA,
2017, pp. 1–3.
[76] A. AbdelSalam et al. (2017). Implementation of Virtual Network
Function Chaining Through Segment Routing in A Linux-Based NFV
Infrastructure. [Online]. Available: https://arxiv.org/pdf/1702.05157.pdf
[77] D. Bhamare, R. Jain, M. Samaka, and A. Erbad, “A survey on ser-
vice function chaining,” J. Netw. Comput. Appl., vol. 75, pp. 138–155,
Nov. 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,” Internet
Eng. Task Force, Fremont, CA, USA, Rep. 7424, Jan. 2015.
[79] F. Aubry et al., “SCMon: Leveraging segment routing to improve
network monitoring,” in Proc. IEEE INFOCOM, San Francisco, CA,
USA, 2016, pp. 1–9.
[80] C. Filsfils et al., “BGP-prefix segment in large-scale data centers,”
Network Working Group/Internet-Draft, 2017.
486 IEEE COMMUNICATIONS SURVEYS & TUTORIALS, VOL. 21, NO. 1, FIRST QUARTER 2019
[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, Fremont, CA, USA, RFC 6805, 2012.
[82] C. Filsfils et al., “Interconnecting millions of endpoints with segment
routing,” IETF Spring Working Group draft-filsfils-spring-large-scale-
interconnect-05, Internet Eng. Task Force, Fremont, CA, USA, 2017.
[83] R. Guerzoni et al., “Multi-domain orchestration and management of
software defined infrastructures: A bottom-up approach,” in Proc. IEEE
Eur. Conf. Netw. Commun., 2016, pp. 1–6.
[84] F. Paolucci et al., “Interoperable multi-domain delay-aware provision-
ing using segment routing monitoring and BGP-LS advertisement,”
in Proc. 42nd Eur. Conf. Opt. Commun., Düsseldorf, Germany, 2016,
pp. 1–3.
[85] X. Xu et al., “Unified source routing instruction using MPLS label
stack,” IETF MPLS Working Group draft-xu-mpls-unified-source-
routing-instruction-00, Internet Eng. Task Force, Fremont, CA, USA,
2017.
[86] Z. AlSaeed, I. Ahmad, and I. Hussain, “Multicasting in software defined
networks: A comprehensive survey,” J. Netw. Comput. Appl., vol. 104,
pp. 61–77, Feb. 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
Proc. IEEE Int. Conf. Commun. (ICC), Paris, France, 2017, pp. 1–6.
[88] C. Kim et al., “In-band network telemetry (INT),” Rep., 2015. [Online].
Available: http://p4.org/wpcontent/uploads/fixed/INT/INT-current-spec.
pdf
[89] F. Brockners et al., “Requirements for in-situ OAM,” IETF Network
Working Group draft-brockners-inband-oam-requirements-03, Internet
Eng. Task Force, Fremont, CA, USA, 2017.
[90] E. Amaldi, B. Fortz, and C. Iuliano, “On finding a minimum weight
cycle basis with cycles of bounded length,” in Proc. CTW, 2010, pp. 5–8.
[91] D. S. Hochbaum and E. V. Olinick, “The bounded cycle-cover problem,”
INFORMS J. Comput., 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 Proc. IEEE Netw. Oper.
Manag. Symp. (NOMS), Kraków, Poland, 2014, pp. 1–8.
[93] N. Ogino, T. Kitahara, S. Arakawa, G. Hasegawa, and M. Murata,
“Decentralized Boolean network tomography based on network par-
titioning,” in Proc. IEEE/IFIP Netw. Oper. Manag. Symp. (NOMS),
Istanbul, Turkey, 2016, pp. 162–170.
[94] J. Blendin et al., “Enabling efficient multi-layer repair in elastic opti-
cal networks by gradually superimposing SDN,” in Proc. 12th IEEE
Int. Conf. Netw. Service Manag. (CNSM), Montreal, QC, Canada, 2016,
pp. 118–126.
[95] M. Anand, R. Subrahmaniam, S. Roy, and R. Valiveti, “Extending seg-
ment routing into optical networks,” in Proc. Opt. Fiber Commun. Conf.,
Los Angeles, CA, USA, 2017, pp. 1–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, Internet Eng. Task Force, Fremont,
CA, USA, 2016.
Authorized licensed use limited to: CHONNAM NATIONAL UNIVERSITY. Downloaded on April 01,2020 at 09:39:45 UTC from IEEE Xplore. Restrictions apply.
Zahraa N. Abdullah received the B.Sc. degree
in computer engineering from Kuwait University
in 2013, where she is currently pursuing the mas-
ter’s degree in computer engineering. Since 2014,
she has been a System Analyst with the Corporate
Application Division, Kuwait National Petroleum
Company. Her research interests include computer
networks and software defined networks.
Imtiaz Ahmad received the B.Sc. degree in electri-
cal engineering from the University of Engineering
and Technology, Lahore, Pakistan, in 1984, the
M.Sc. degree in electrical engineering from the
King Fahd University of Petroleum and Minerals,
Dhahran, Saudi Arabia, in 1988, and the Ph.D.
degree in computer engineering from Syracuse
University, Syracuse, New York, in 1992. Since
1992, he has been with the Department of Electrical
and Computer Engineering, Kuwait University,
Kuwait, where he is currently a Professor. His
research interests include design automation of digital systems, high-level
synthesis, and parallel and distributed computing.
Iftekhar Hussain received the B.Sc. degree
in electrical engineering from the University of
Engineering and Technology, Lahore, Pakistan, the
M.S. degree in electrical and computer engineering
from the University of Tennessee, Knoxville, TN,
USA, and the Ph.D. degree in electrical and com-
puter engineering from the University of California,
Davis, CA, USA. He is currently a Senior Principal
Software Architect with Infinera Corporation, where
he is involved in design of IP/MPLS control and data
plane system architecture of high-capacity packet
switching systems for data center and core network applications. His research
interests include routing, switching, computer vision, and machine learning.