Segment Routing
Segment Routing
29 de agosto de 2018
The versatility of segment routing in terms of deployment, distributed versus centralized, network
types, data centers/WANs/access, and use cases makes it a solid option for end-to-end network
deployment
Service providers and large enterprises face stiff challenges: the network infrastructure and their
operations are growing at tremendous pace and becoming complex. IP/MPLS networks have
become operation intensive because of their complex implementations. Service providers feel the
added pressure of falling revenues and stiff competition by the over-the-top providers as well as the
challenge to innovate. These drivers make the network owners think about a transport technology
that can provide convergence across layers, domains and offload the complexities in the networks
today.
One of these technologies is Segment Routing (SR), which has caught the attention of the network
planners because of its potential to simplify and unify the transport layer. It is a source-based
routing technology that enables IP/MPLS and IPV6 networks to run more simply and scale more
easily. Segment Routing eliminates resource-heavy signaling protocols of MPLS and moves
intelligence to the source/edge of the traffic thus removing complexity from the network. In the IPV6
networks, SR opens new possibilities of network programming and opens new avenues of flexibility,
control and feature-rich use cases.
1
Segment Routing is a promising technology that can be seamlessly deployed in today’s MPLS and
IPV6 networks. The versatility of the technology in terms of deployment (distributed versus
centralized), network types (data centers or WAN), diverse use cases makes it a good candidate for
deployment in any kind of WAN, data center, access, metro or virtualized environment.
2
INTRODUCTION
Service providers’ and large enterprises’ networks are growing at a tremendous pace and becoming
more complex and difficult to manage. This results in an increase in operation expenses (opex) and
has forced the network owners to ask if there is a leaner and simpler way to manage and run
networks. Is Segment Routing (SR) the answer to these network problems?
3
Segment Routing is a source-based routing technology for IP/MPLS and IPV62 networks. Although
still in its infancy because the standardization activity is in progress, the industry is backing it up
heavily. This can be gauged by the number of Internet drafts3, which are under progress in the
Internet Engineering Task Force (IETF).
This paper introduces Segment Routing concepts and their benefits. It describes several use cases
to enable the business leaders/decision-makers in the networking industry to understand its
emerging applications.
Segment Routing is a source-based tunneling technology where a source chooses a path. The
information is encapsulated in a packet header as an ordered list of segments, which sends the
information, including the detour information, to its destination around the network.
SR can be applied in both IP/MPLS and IPV6 networks. In IP/MPLS networks it can be implemented
without changing the data plane; in IPV6 networks it can be applied by adding a new routing
extension header. SR when applied in IPV6 networks is also called SRV6.
Vendors and service providers initiated the development of SR. In May 2016 the authors of RFC
78554 pointed out that the current networks could not easily fulfill requirements and there was a
need to have simpler and flexible networks utilizing Segment Routing for:
4
SIMPLE, SCALABLE AND ECMP FRIENDLY
LDP and RSVP-TE are the de-facto signaling and label distribution protocols in IP/MPLS network
used for years, but are they scalable?
Control Plane Sessions: For LDP each router maintains sessions (LSPs state), which are equal to
the number of LDP neighbors. For RSVP-TE, the number of sessions is equal to the total number of
LSPs in which the router is involved (whether ingress, egress or transit). In the RSVP-TE case, if a
topology includes N fully meshed routers, there will be a need to maintain a state of N x N (N
square) LSPs in each router. This quickly runs into an N square problem because the number of N
increases. From a control session perspective, RSVP-TE can run into scalability issues.
FORWARDING STATE
LDPs maintain forwarding state of all Forwarding Equivalence Class (FEC) in the network, because
each FEC is reachable by any other LDP router in a network. RSVP-TE only keeps the forwarding
5
state of the LSPs that traverse through it and potentially their protection path. From forwarding state
perspective, LDP runs into scalability issues if a network becomes extremely large.
RSVP-TE can also perform traffic engineering in IP/MPLS networks; however, it involves complex
tunnel configurations on interfaces and is difficult to troubleshoot. LDP cannot do traffic
engineering, but it can lose synchronization of the LDP and IGP because LDP depends on IGP for
route convergence.
SR is scalable6 because it does not rely on LDP/RSVP-TE, and there is no need of keeping
thousands of labels in an LDP database. It avoids thousands of MPLS traffic engineering LSPs in the
network.
R uses extensions to existing IGP protocols for signaling purpose. Relying on IGP has other benefits
too; it can take advantage of Equal Cost Multi-Path Routing (ECMP) to load balance across multiple
available paths in the network and gain better bandwidth utilization. This kind of flexibility does not
exist in current RSVP-TE, which would need complex manual configurations for ECMP functionality.
6
TECHNOLOGY BEHIND SEGMENT ROUTING
SR uses segments and segment identifiers (SID). A segment is a basic unit in SR. By combining
multiple segments, an end-to-end route can be created. If traffic needs to go from ingress at A to
egress at H with a diversion at E, then the three segments are enough to define the path (Figure 2).
Additionally, there be should some identifier associated with the segment; this identifier is called
Segment Identifier. The end-to-end path is also sometimes denoted as a SID list (SID 1, SID 2, and
SID 3).
7
In MPLS, a segment is encoded as an MPLS label. A stack of labels represents an ordered list of
segments. The top label is the one that is processed by the node that receives it. Upon processing
the packet, the top label is popped from the stack.
In IPV6 a new routing header is defined to enable Segment Routing. A segment is encoded as an
IPV6 address. An ordered list of IPv6 addresses represents an ordered list of segments. The
destination address of the packet shows the active segment.
TYPES OF SEGMENTS
8
Within an SR domain, an IGP node advertises segments for its attached prefixes and adjacencies.
These are called IGP segments. Advertisements of IGP segments require extensions to link-state
IGP protocols such as OSPF and IS-IS.
IGP Prefix Segment depicts a path to an IGP Prefix. It is an ECMP aware segment. Its segment
identifier is called Prefix SID.
The SID value (which is unique within SR domain) is allocated from a unique pool called the SR
Global block (SRGB).
Every router is identifiable by a unique Prefix SID in the network so that other routers know where to
send the traffic once it sees that SID.
When SR is used in MPLS, Prefix SID is allocated in the form of an MPLS label. When SR is used in
IPv6, Prefix SID is allocated as an IPv6 address.
IGP-Node Segment, Node-SID: IGP-Node segment is a special subtype of Prefix Segment. The
Node Segment signifies a path to a node (for example, a loopback) in an IGP domain; it is identified
by Node SID value, which is unique in the SR domain.
IGP-Anycast Segment, Anycast SID: IGP-Anycast Segment is a special type of Prefix Segment that
shows ECMP aware path toward the closest node of anycast set. It points to a group of routers with
a common SID value called Anycast SID.
IGP-Adjacency Segments: These are local to each node and are installed and advertised only on
directly connected neighbors, identifying a specific adjacent link. IGP-Adjacency Segment is
identified by Adj-SID, which is dynamically allocated by a node (outside the SRGB block). If a router
9
has four adjacent links, it will allocate a unique Adj-SID to each one of them. Once it sees that Adj-
SID in the incoming label stack, it knows on which link the traffic should be forwarded.
BGP SEGMENTS
There are two kinds of BGP segments allocated and distributed by BGP.
10
Use Case: Fast Re-Route (Topology Independent LFA)
SR runs in service provider networks that provide mission-critical services, which require recovery
from failure that is quick, simple and predictable. It is a default requirement to have failure recovery
in less than 50 milliseconds.
There has been continuous improvement in the resilience mechanisms in IP/MPLS networks: RSVP-
TE-Fast reroute, Loop Free Alternate (LFA) and remote LFA, which has seen wide adoption. Although
mechanisms have improved, there are none that can guarantee 100% coverage for all failure
scenarios. It is not uncommon to see that LFA converges on a path that is suboptimal. SR solves the
issue of micro-loops7 that may happen in in LFA. SR utilizes Topology Independent LFA (TI-LFA)8
that can provide loop-free guaranteed coverage against link, node and local SRLG failure in 100% of
cases.
11
LFA does not provide 100% coverage; however, Transport Independent LFA with Segment Routing
does not need any targeted LDP session. This makes the protocol very simple and scalable.
In the same scenario in Case 3, for the protection route, at the ingress router R1, three
segments are built using three SID labels:
12
Using Adjacency SID at Node R3 has solved the issue of crossing the high metric link from R3 to R4;
when the traffic reaches Router R3 and sees the Adjacency SID label Adj R3-R4 it immediately
knows that it needs to send the traffic on the adjacent link to R4 irrespective of the metric on this
link. Segment Routing has solved the protection problem easily by building three label stacks
without any need of targeted LDP session.
In addition to link failures, Segment Routing also provides node and SRLG protections9.
13
TI-LFA Advantage: Optimal Post Convergence Path
Remote LFA sometimes does not converge on an optimal path on the protection route. In the
scenario in Figure 10 there is a break on the primary link between Router R1 and Router R5 (green
path). The remote LFA chooses R3 (PQ node) as its next hop for protection traffic (red path)
although its metric is high instead of sending the traffic through R2, which is low metric link. It
cannot send it to R2 because the shortest path of R2 to the destination is through R1, which would
create micro loops. TI-LFA solves this issue by stacking two Prefix SIDs (blue path). The top label
points to R2, forcing the packet to choose R2 as its next hop and the next label (Prefix SID) points to
destination R5, easily solving the suboptimal convergence issue. TI-LFA follows the natural path of
the IGP convergence. In the example, traffic from R1 to R5, if R1-R5 link is not available, is always
through R2.
14
USE CASE: TRAFFIC ENGINEERING (SRTE)
SRTE has become one of the widely adopted use cases for Segment Routing because of the
simplicity and scalability it provides. Traffic engineering in MPLS until now has rarely been
implemented in large service provider networks because of the complexity. Not only does SRTE
provides simplicity and scalability but also provides an SR native way of implementing traffic-
engineered paths that take advantage of the ECMP behavior of IP. Complexity is further reduced in
the network because of the additional benefits of automation through on-demand SR policy
implementation and automated traffic steering in the network.
15
• Headend, where policy is initiated
• Color, an arbitrary numerical value that shows differnt policy types, for example, green for
low-latency path; red for high bandwidth path
In the following case two different policies are configured: green with low latency and red with
higher bandwidth. A policy can have multiple candidate paths. For example, red policy has two
paths. The preferred candidate path among multiple candidate paths is identified by the highest
preference number (one of the parameters of candidate paths) among them.
16
RSVP-TE, the protocol for traffic engineering in IP/MPLS, is not popular because of the need to
create a lot of tunnel configuration for TE policies. It quickly runs into scalability problems because
of these issues.
SRTE keeps core very light and scalable (as core is stateless). SRTE supports both explicit routing
and constraints-based routing such as RSVP-TE. Using constraints-based routing, flexible policies
can be created automatically in centralized and distributed environments based on latency,
disjoints and preferred paths, etc.
Instead of using algorithms of RSVP-TE to calculate the best path based on constraints, SRTE uses
SR Native Algorithm. This results in label stack reduction and a path that is load balanced because
SR has ECMP native capabilities.
In Figure 13, conventional TE mechanisms are compared with SR Native TE mechanisms to find a
traffic engineered path between A and F that does not pass through the red link. In conventional TE
mechanisms the single best path is calculated through B, C, D, and E routers.
This is more like a classical TDM approach in which one path (instead of multiple paths) is utilized
for traffic transfer and does not take advantage of load balancing across equal cost links (to have
ECMP in RSVP-TE would require additional configurations and complexities).
Because SR natively supports ECMP, it utilizes all equal cost paths, which also results in fewer
segments. For example, just pointing to Prefix E, will load balance the traffic across available three
links. By using just two SIDs E and F as label stacks, traffic can reach destination F, utilizing three
paths.
SR achieves the traffc engineering objectives with an SR native approach and with fewer label
stacks (shorter SID list).
17
SRTE has a novel way of instantiating SR policy on demand instead of configuring it beforehand. SR
policy can be instantiated on demand based on BGP Next Hop. This creates a very dynamic, flexible
and automatic way to apply policies. Not only can the policy be instantiated on demand, but traffic
can be automatically steered (because of BSID) based on the forwarding plane set by the on-
demand SR policy.
The on-demand policy makes traffic engineering very simple, automatic and lightweight. This
contrasts with RSVP-TE that needs to have policies preconfigured with complex tunnel
configurations. For example, on-demand SR concept with automatic steering: Customer A buys a
premium low-latency service and Customer B a basic VPN service (lowest IGP metric) from the
service provider.
The challenge is to configure policies on the fly once BGP routes are installed and then steer traffc
according to the new policies. Router R5 at the destination advertises two BGP routes: green for low
latency VPN and red for basic VPN based on lowest IGP metric. Once the SRTE process at R1 sees
two different colors in the BGP advertisement, it will create two policies:
18
19
SRTE Advantage: Multidomain Capable
SRTE is multidomain capable and designed in way that it can run in a multidomain environment
with or without a centralized controller. To validate paths and compute dynamic paths, the SRTE
process maintains an SRTE-DB that can run flexibly in a headend router or a centralized controller.
The attached domain topology can be learned via IGP, BGP-LS or NETCONF. A nonattached
(remote) domain topology can be learned via BGP-LS or NETCONF. In a centralized environment,
automated PCE assistance can create end-to-end uniform policy-based constraints such as
latency, disjoints and SRLGs.
20
Use Case: Flex Algorithm
Flex Algorithm adds to the capabilities of SRTE. It does so through a new prefix segment, which is
defined for a common objective such as minimize the igp-metric/delay or, for example, avoid a
certain SRLG.
Many different types of constraints can be defined. For example,, in a network with dual plane, a
constraint would be to use a certain plane and avoid the other plane. SR allows computing paths
with these constraints using certain algorithms. It then allows Prefix SID to be associated with these
algorithms. They are called Flex Algorithms.
To provide maximum flexibility there is no strict mapping between the set of constraints and the
algorithm associated with it. The mapping between the algorithm value and its meaning is flexible
and defined by the user. The only requirement is that the routers participating in the domain should
have common understanding of the algorithm value, hence the name flexible algorithm.
Flex Algorithm provides a new prefix segment to achieve one of the following objectives:10
21
• Avoid SRLG or affinity
One of the interesting use cases for Flex Algorithm is the implementation of dual plane connectivity.
Traffic is divided between two different planes. In the following the Flex Algorithm128 is associated
with the red plane and Flex Algorithm129 is associated with the green plane.
Routes with Prefix SID 128 will stay in the red plane and the routes with Prefix SID 129 will stay in the
green plane. Even in case of fiber cut, for example, the protection route for red plane will stay in the
red plane and the same for the green route. It is clear that the use case of dual plane connectivity
can be achieved very easily by just using one Prefix SID defined through flexible algorithm.
22
USE CASE: SOFTWARE DEFINED NETWORKING
When used in centralized environment, Segment Routing gives a de facto SDN architecture as there
is no state in the network (only on the edge), and the traffic paths are computed and programmed
by a centralized controller, which is usually Path Computation Engine.
By logically centralizing the control of the network, it is possible to program per-flow routing based
on TE goals. With limited state in the network, SDN centralized controller can actively collect
topology information from the network using existing protocols such as BGP-LS and then compute
the best paths based on the constraints defined by a user.
Not all applications have equal value. Some are delay sensitive (financial transactions and VoIP);
some are bandwidth intensive (data centers replication); and others need low jitter (video). Rather
than manually configuring these tunnels, which may run into thousands, and managing them, such
tasks can be handed over to a centralized SDN controller12 . By integrating them with the
application layer that can tell the requirements to the controller about SLA needs for the end-user
applications, the controller can react in an agile way to the application routing in the network.
23
SRV6 USE CASE: NETWORK PROGRAMMABILITY
SR in IPV6 (SRV6) opens new paradigms that go beyond simple networking expected from SR. It
brings the concept of instruction sets (functions) that enables complex network programming
models.
Network programming can result in the collapse of technologies. One example is service chaining
in NFV, in which a packet must travel to different service nodes (virtual machines) and perform
different functions. In the presence of SRV6 underlay13 and the capabilities of SRV6 to support
instructions in SRV6 header, overlay and service layer functionality can be implemented easily in
SRV6. This means there is no need for additional layers as SRV6 can eliminate both the overlay and
the service layer and replace it with additional SRV6 headers to perform the functions of these
layers. The network becomes simpler and run with fewer protocols.
24
HOW SRV6 ACHIEVES NETWORK PROGRAMMING?
Network programming is one of the powerful features of SRV6 and enables different functions to be
associated with the SIDs in SRV614. In Figure 20 the SRV6 SID has two parts: a locator part that
identifies the address and a corresponding function part that is an instruction executed at the
location described by the locator part. There is also a metadata TLV attached as a global argument
to the SRH header that can be used to carry additional information, for example, credentials and
performance information.
The behaviors of these functions are entirely up to the implementer. For example, these functions
can be forwarding, encapsulation, decapsulation, L2 or IPV4 cross-connect, instantiation of SRV6
policy or combination of these actions. Any function can be attached to the SID. These stacks of
segments act like a network program that can treat packets in different ways, going beyond just the
25
forwarding functions that normal transport does. Very complex network functions can be executed
in the network through the network programmability features of SRV6.
Service Function Chaining (SFC) is the process of steering traffic through an ordered list of
functions, for example, load balancer, firewall and proxy.
SFC is defined by IETF. Network Service Header (NSH)15 is part of SFC. It is imposed on packets or
frames to realize service function paths. SR can achieve SFC because it can execute one function
after the other based on the SRV6 header stack. However, since SR is inherently stateless and
policy is only encoded at the ingress of the network, it is more scalable compared to NSH, which
relies on the state configured at every hop of the network.
In Figure 21, the service chain shows different functions running on either virtual machines or
containers in an NFV environment. Two different service chains are created. The applications can
be SR aware or not (SR case proxy function can be used).
SRV6 enables offloading a multicast core using Unicast flows to reduce complexity. This is one of
the leading service provider use cases called Spray .
In Figure 22, a service provider is peering with a content provider. The content provider replicates
the information to every Cable Model Transmission System (CMTS) in different regions through a
traffic-engineered core. The CMTSs will then perform the multicast function, which is done by
establishing Unicast flows in the core. A spray policy is added at the headend for different flows
(green and orange) regions, which will enable the flows to steer through the network as Unicast
traffic. The overall complexity of the core is greatly reduced by the offload of multicast protocols in
the core of the network.
26
SRV6 USE CASE: 5G
SRV6 will play an important role in 5G transport, so much so that it has the potential to replace the
major tunneling protocol in the user plane called GTP-U.
In mobile networks, GTP-U is used as the tunneling protocol to carry user data in GPRS, UMTS and
LTE networks (also part of 5G). Tunnels are created per session, Figure 23. The current mobile
networks are rigidly fragmented between radio access, core (EPC) and service network. Tunneling
techniques are used to connect these domains through anchor nodes. Such rigidness makes it
difficult for the operator to optimize the data
27
SRV6 can be used as a replacement for GTP-U in 5G to make the transport much simpler. TEID is
used in GTP-U as an identifier to stitch different nodes. As SRV6 has SID field, so it can easily
encode the TEID information therefore paving way for replacing GTP-U altogether. Not only can
SRV6 replace the GTP layer, but also any underlay transport layers (for example MPLS or any other
L2 tunneling protocol) paving the way for the introduction of SRV6/IPV6 as the only transport layer
in 5G.
The 5G core is a virtualized one with complex NFV based service chain requirements in its transport
layer. The inherent capability of SRV6 to provide service chaining and network programmability
makes it an ideal protocol to be used in 5G environments.
Network slicing is one of the other main features of 5G transport. A common network infrastructure
enables network slices depending on different SLA requirements. Each slice represents different
network characteristics depending on different SLA requirements for latency, throughput and for
different use cases, mobile broadband, Internet of things, etc. The benefit of creating network
slicing through SRV6 is the ease through which the network slicing/virtualization can be achieved
because of the SRV6 native capabilities such as tunneling, SRTE and network programmability. This
eliminates the need for any additional tunneling protocols to achieve such network slicing.
The versatility of the use cases and features makes SR suitable to be used in any part of the
network: access, metro, backbone or data center, enabling a unified fabric end to end, and
eliminates the need of running different transport protocols in different part of the network.
28
Working with a unified transport protocol such as SR in end-to-end domains has many benefits:
although it makes the operation easier, the major benefit is the elimination of re-classification at
the domain boundaries. For example, one common issue in a mobile backhaul network is the
challenge of setting up consistent quality of service (QoS) scheme across access, metro and core.
In the absence of a consistent QoS, the network cannot fulfill consistent end-to-end SLA
requirements. Issues can be avoided if there is only one transport protocol. With one unified fabric,
all the advantages of SR can be utilized: end-to-end TI-LFA, end-to-end on-demand SR policy, end-
to-end automatic steering and consistent 50msec recovery time no matter when the link cut
happens.
Segment Routing offers innovative and enhanced OAM features, including Path Monitoring System
(PMS), traditional LSP Ping and traceroute tools.
In Figure 27, to monitor the path between Nodes F and D, PMS does it in two steps. In a first step it
discovers all the reachable paths from F to D through the path trace message from Point F. From
this information, it builds up monitoring packets that it generates from PMS with the label stack
(Prefix F, Prefix D, Prefix PMS). For example, the packet travels to Node F, then Node D and returns to
29
PMS. In this way PMS has complete visibility and status for the link between F and D. This is a novel
way of path connectivity monitoring because it does not require any MPLS OAM functionality. All
monitoring packets stay in the data plane; path monitoring does not require any control plane
interaction in any node. Many operators prefer this way of central connectivity validation
mechanism.
raffic matrix collection is key to successful traffic engineering and capacity planning. Traffic
collection is complex in current IP networks because it can involve many configurations on the
nodes. Traffic counters are enabled (for example, NetFlow, SNMP MIB, MPLS and MIBS) and the
data is collected and sent to a central engine to process and give a report on the traffic matrix.
When Segment Routing is enabled in a network, the traffic collection process is automated thereby
making the traffic engineering and capacity planning process much simpler and convenient.
30
CONCLUSION AND RECOMMENDATIONS
31
Service providers need to reduce current complexities in their networks to compete efficiently with
the webscale over-the-top providers. Network owners have only two options: either continue to
grow with the complexities and lose more on capital expense and operational expense or think
outside of the box with Segment Routing to solve these issues.
32