As more and more Service Providers and Enterprises operate a single network infrastructure to support an ever-increasing number of services, the ability to custom fit transport to application needs is critically important.
In that respect, network operators have been exploring Traffic Engineering techniques for some years now but have obviously run into many scaling issues preventing them from having an end-to-end, fine-grained control over the myriad services they offer.
We firmly believe Segment Routing Traffic Engineering (SR TE) has changed the game and has become the undisputed solution to deliver Traffic Engineering capabilities at scale.
What makes SR Flexible Algorithm a noteworthy addition to SR TE solution?
Let’s quickly revisit how SR TE works with an example.
Imagine you want to offer a low-latency service to a financial institution, that has offices in both London and Berlin. If the High-Bandwidth path from London to Berlin is via France, the low-latency path via Brussels could be expressed with the following SR policy <Brussels, Berlin>. The first segment Brussels steers the application via the northern path providing low latency.
More generally, a computation engine (could be a router or a PCE) collects the network topology and its related segments and expresses the intent (the SR Policy) as a list of segments, each segment being the shortest-path according to the IGP metric.
Flexible Algorithm enriches the SR TE solution by adding additional segments having different properties than the IGP Prefix segments. For example, while the IGP Prefix Segment to Berlin follows the IGP shortest-path (the south route via Paris because of the availability of more and cheaper capacity), the Low-Latency Flex Algo Segment to Berlin (lets’ call it Berlin-Latency) steers the traffic via the Brussels route offering the low-latency experience.
Coming back to our example. Let’s assume now that:
- Each router monitors the latency of each of its links and floods these information into the IGP
- Each router is configured with a new Segment Routing Identifier (SID) tied to the latency TE property.
- Each router computes the shortest-path as per the new latency metric
- <Berlin-Latency> is the “latency” SID for Berlin.
The low-latency SR policy from London to Berlin can then be expressed with a single SID <Berlin-Latency>.
This new flavor of Segment Routing Identifier is called an “IGP Flex Algo” SID:
- IGP because the IGP floods specific TE metrics and computes the related shortest path
- Algo, for Algorithm, because we associate to the SID a specific TE intent expressed as an optimization objective (an algorithm). Each objective is known by an Algo number.
- Flex, for Flexibility, as network operators can define the intent of each algorithm they implement. In addition, operators can also make the decision to exclude some specific links from the shortest path computation:
- operator 1 may define Algo 128 to compute shortest path for TE metric and exclude red affinity links
- operator 2 may define Algo 128 to compute shortest path for latency metric and exclude blue affinity links
The same intent (SR Policy) for a low-latency path from London to Berlin can thus be expressed as <Brussels, Berlin> or <Berlin-Latency>. Extending this to a multi-domain use-case between two hosts A and Z in two different data-centers DC1 and DC2, an end-to-end low-latency policy from host A to host Z can be conveniently expressed as <DCI1-latency, DCI2-latency, Z-latency>: i.e. the low-latency path to the DCI of DC1, then the low-latency path to the DCI of DC2 and then the low-latency path to host Z.
Each of these IGP Flex Algo segments leverage the automated 50msec TILFA protection with the added benefit that the backup path respects the same constraint as the primary path: e.g. the backup path for Berlin-Latency may be different than the backup path for Berlin. The first is optimized to avoid the failure and minimize latency while the second is optimized to avoid the failure and prefer paths with cheaper/more capacity.
This latest addition to SR TE is leveraging the simplicity and automation properties of the SR TE solution: on-demand policy generation and automated steering are readily applicable to policies based on IGP Flex Algo. This tremendously simplifies the network operation.
This new SR TE capability makes multiple optimizations of the same physical network infrastructure along various dimensions possible – one can be optimized for low-latency vs. another one for bandwidth, one can offer disjoint paths via two distinct planes. It also plays a major role to custom fit 5G network slices to specific applications.
Interestingly, Flexible algorithm is already gaining traction with some customers.
“Flexible Algorithm is very valuable addition to SR TE solution that allow to auto-steer unicast and multicast traffic via any topology/path based on operator defined logic. Ease of configuration and operational management, ability to provision dynamic constrained paths based on a single SR label with local repair (TI-LFA) respecting the same constraints as the primary path are some of the benefits that we might realize with Flexible Algorithm.” says Arkadiy Gulko – Senior Network Architect with Thomson Reuters.
Over the next few years, Traffic Engineering solutions will play a major role as Service Providers and enterprises get ready to offer a wide range of 5G services. All of these services have specific and differentiated needs – some are sensitive to latency, some need to be highly-resilient and others are bandwidth-hungry – forcing network operators to implement top-notch TE solutions across their network, directly from the cell site and up to the core and data centers. Scale and magnitude of these upcoming implementations necessitate to rethink entirely current TE solutions and that’s the reason why more and more operators are testing and rolling out SR TE solutions in their current network infrastructure.
Do not hesitate to contact your local team to request a demonstration of the various use-cases offered by SR IGP Flex Algo: low-latency, dual-plane, affinity exclusion as well as applicability to MLDP tree, integration with on-demand policy and automated steering. Don’t forget to visit our dedicated website as a detailed tutorial will be available in the next coming weeks.
CONNECT WITH US