The Current and Future Status of MPLS-TE Part 2: Segment Routing

In this second of our two-part blog series on MPLS Traffic Engineering, we introduce Segment Routing for Traffic Engineering (SR-TE) and examine its advantages over RSVP-TE.

As we outlined in part one, many of today’s MPLS networks are built with Traffic Engineering (TE) capabilities. With TE, a network operator can optimize and make better use of its IP/MPLS network infrastructure. TE helps in congestion avoidance, provides Fast Reroute (FRR) in case of link failure, and allows a head-end router to re-optimize an existing TE tunnel path by using newly available resources. All of this helps enhance the performance of an MPLS label switched path (LSP).

Currently, the go-to technology for network operators to build traffic engineered MPLS networks is RSVP-TE. But today, we are seeing the adoption of another protocol that not only helps enable traffic engineering but can also be used by software-defined networking (SDN) applications to automatically provision new paths. It’s time to look at Segment Routing.

What is Segment Routing?

Segment Routing (SR) is not a new technology but only recently has it been embraced by all the major network equipment vendors. It is a packet forwarding technology where the source node defines the path for traffic, which is then sent through specific nodes and forwarding paths called segments. An SR path is not dependent on hop-by-hop signaling, Label Distribution Protocol (LDP) or RSVP. Instead, it uses segments for forwarding.

What is Segment Routing

SR, like MPLS, uses label switching to forward packets, but in SR terminology the labels are called segments. There are two types of segments. A node segment identifies the shortest path to a destination node (e.g., R1 to R3 in the diagram). The node segment is advertised throughout the network, and all remote nodes install the segment in their respective MPLS data planes. The other type is an adjacency segment, which represents a link between two nodes that are adjacent (e.g., R2 to R5).

Each node in an SR domain is also given a globally unique identifier known as segment identifier (SID) by the network operator. The SR node then allocates a local SID for each of its adjacency segments, which are stored only by that specific node in its data plane.

When a Segment Routing tunnel is created it either contains a single segment that represents a path to a destination or a segment list, which is a set of segments that the tunnel will encode to reach its destination. In the below SR domain, traffic from node A to Z traverses a node segment that carries traffic to C, adjacency segment CO that represents the link from node C to O, and then again uses a node segment that carries traffic from O to Z.

What is Segment Routing

By using segments, SR can ignore the shortest or lowest cost path preference of IGP, which may be congested as we discussed in part one, and encode any path in the MPLS network to route traffic to destination. This gives the operator the ability to steer traffic over different paths based on the requirements of the traffic and the state of the network. For example, an operator can send voice traffic over a low latency path and bulk data over a high latency path using SR.

For detailed information on configuring Segment Routing on Cisco IOS XE, check out:

http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/seg_routing/configuration/xe-3s/segrt-xe-3s-book/intro-seg-routing.html

For information on enabling segment routing capabilities with OpenDaylight, IOS-XR 6.0.0, and the Packet Design SDN Platform, check out:

http://www.packetdesign.com/blog/segment-routing-with-opendaylight-beryllium-a-packet-design-how-to/

RSVP-TE is not dead. But long live Segment Routing.

Network operators running IP/MPLS networks need the ability to optimize their existing network infrastructure. This means an operator needs more control over its network routes and granular control over the traffic data. Segment Routing can provide this. SR supports Class of Service-based TE (CoS) where one can define per-flow CoS policies and encode a segment to fulfill the CoS demands. RSVP-TE has failed to provide this level of granular control due to scalability issues.

Another factor is that SR removes the needs for protocols such as LDP or RSVP and uses fewer numbers of labels compared to an LDP or RSVP-TE deployment. SR also does not use signaling, allowing it to scale significantly better than RSVP-TE while simplifying the network.

SR comes with automated and native FRR capabilities and provides a convergence time of sub 50-msec FRR in any topology.

SR can also work with Path Computation Element (PCE) to enable an agile WAN-SDN. SR with our SDN Platform can be used to provision TE tunnels automatically and provide value-added services such as bandwidth management, bandwidth calendaring, and bandwidth on-demand.

These capabilities of SR provide a major advantage to enable seamless MPLS networks while continuing to provide all the TE functions that RSVP-TE does.

Related Reads:

PCE Tunnels with ONOS Goldeneye

http://www.packetdesign.com/blog/pce-tunnels-onos-goldeneye-packet-design/

A Case for Segment Routing and YANG Data Models: Keeping the WAN SDN Underlay Simple

http://www.packetdesign.com/blog/a-case-for-segment-routing-and-yang-data-models-keeping-the-wan-sdn-underlay-simple/

Hopefully, you are now ready to explore more of Segment Routing for Traffic Engineering in your MPLS network.

Explorer Suite | Resources | Request Demo | About Packet Design | Follow us on Twitter

Packet Design Route Explorer for Traffic Engineering