The Internet was initially designed to provide best-effort connectivity over a least-cost path. Relatively few sites were connected to the Internet, and within those sites, only applications that satisfied an acceptable use policy could be connected.
Today, billions of businesses, households and devices are connected to the Internet. Critical applications include telemedicine, traffic control and financial transactions. Some applications (e.g., email) are tolerant of loss, latency and latency variation, while other applications (e.g., gaming) are significantly less tolerant.
In today’s Internet, many applications require more than best-effort connectivity over a least-cost path. Because these applications are ubiquitous, network operators must deliver advance services such as traffic engineering and fast reroute at scale. In order to deliver these advanced services at scale, they must reduce network complexity.
Segment Routing (SR) offers an innovative approach to traffic steering. This approach can be applied to long-standing problems such as traffic engineering and fast reroute. When applied to these problems, SR can simplify routing protocols, network design and network operations.
Many network equipment vendors offer interoperable SR implementations. However, SR innovation continues at Juniper Networks and throughout the industry. This series of blogs is intended to guide the reader through this Segment Routing Renaissance.
In order to understand recent SR innovations, the reader must first acquire an intuitive understanding of SR fundamentals. Therefore, one goal of this blog series is to revisit SR fundamentals. This exposition of SR fundamentals will include insights gained from implementation and experimentation, as well as a review of early specifications.
Another of this blog series is to address best practices regarding SR deployment and operations. And finally, this blog series will address gaps, new requirements and recent SR innovations.
We’ll begin by introducing the SR domain and the SR Path.
SR Domain
An SR domain is a collection of nodes that participate in SR protocols. Within an SR domain, a node can execute ingress, transit, or egress procedures. Figure 1 depicts a network in which a source node sends a packet to a destination node. The source and destination nodes reside outside of the SR domain, but the path between them traverses the SR domain.
When the packet arrives at the SR ingress node, the ingress node subjects the packet to policy. Policy includes match conditions and actions. If the packet satisfies match conditions, the SR ingress node can encapsulate the packet in an SR tunnel. The SR tunnel traverses an SR path to the egress node.
The SR path can be engineered to satisfy any number of constraints (e.g., minimum link bandwidth, maximum path latency). While an SR path can follow the least cost path to the egress node, constraints can cause it to follow another path.
In many cases, the source node and the SR ingress node reside on independent hardware platforms. For example, the source node can be a laptop while the SR ingress node is a router. However, this is not always the case. In some cases, the source node can be a virtual machine, while the SR ingress node is a hypervisor. Both can reside on the same hardware platform.
Likewise, the SR egress node and the destination node can reside on independent hardware platforms. However, they can also reside on a single platform.
In a less typical configuration, the source node resides inside of the SR domain. In this case, the source node is also the SR ingress node, because it executes SR ingress procedures. Likewise, the destination node can also reside inside of the SR domain. In this case, the destination node is also the SR egress node, because it executes SR egress procedures.
SR Path
An SR path is an ordered list of segments that connects an SR ingress node to an SR egress node. While an SR path can follow the least cost path from ingress to egress, it can also follow another path.
Many SR paths can share a single segment. Figure 2 provides an example, in which Path A connects Ingress A to Egress Z, while Path B connects Ingress B to the same egress node. Both paths traverse Segment 3.
When an SR ingress node encapsulates a packet in an SR tunnel, it encodes the associated segment list in the tunnel header. It then forwards the packet downstream. Transit nodes process the tunnel header, forwarding the packet from the current segment to the next segment.
Because the SR ingress node encodes path information in the tunnel header, transit nodes are not required to maintain information regarding each path that they support. They are only required to process the tunnel header, forwarding the packet from the current segment to the next segment.
This is the major benefit of SR. Because transit nodes are not required to maintain path information, overhead associated with maintaining that information is eliminated. Routing protocols are simplified, scaling characteristics are improved, and network operations become less problematic.
While encoding path information in the packet and removing it from the transit node introduces some new challenges, the engineering trade-offs are largely positive. These engineering trade-offs will be discussed in subsequent blogs.
Next Installment
In the next installment of this blog series, we will provide a more complete definition of segments and segment types.
Join us on June 10 (US/EMEA) and June 11 (APAC) to discover how network architectural shifts create business value at our Juniper Virtual Summit for Cloud & Service Providers. Register here.
