Cisco CNC and SR-TE, Better Together
In This Article
In a previous article, we talked about SR-TE and how it dramatically simplifies the configuration model and eliminates the RSVP soft-state requirements in favor of source packet routing. We discussed many SR-TE enhancements like expanding path selection beyond the default high-bandwidth path in favor of a dynamic low-delay path or a high-bandwidth path with a bound delay or the addition of path constraints. Now we add Cisco Crosswork Network Controller (CNC), which offers several enhancements for building SR-TE networks. Cisco Crosswork Network Controller (CNC) is a network automation platform for deploying and operating IP transport networks. CNC provides two key features not available with SR-TE alone: Local Congestion Mitigation (LCM) and Bandwidth on Demand (BWoD) which we will discuss in this article.
We start with a brief overview of Crosswork Network Controller or CNC. CNC is a Segment Routing SDN Controller for transport networks. CNC allows an operator to create and manage VPN and Transport services with diverse SLAs such as disjointness, bandwidth awareness or low latency. It provides for the creation of engineered Transport paths using SR-TE parameters and the provisioning and linking of VPN services to these paths. CNC performs real-time network optimization based on current network conditions utilizing the Crosswork Optimization Engine in conjunction with Cisco's IOS-XR based Segment Routing Path Computation Element or SR-PCE. Cisco NSO is also included and tightly coupled to CNC as the Provisioning engine.
Now, let's discuss the first CNC enhancement, Local Congestion Mitigation (LCM), a feature that is interval driven rather than triggered. This means that the CNC searches for congestion on a configurable interval and provides recommendations to alleviate congestion on a local interface level. LCM attempts to keep as much traffic on the original IGP path as possible while redirecting enough traffic to a tactical policy to alleviate the congestion. LCM will not alter the original SR-TE policies on identified links during congestion mitigation and only attempt to redirect native IGP traffic. You can commit the LCM recommendations automatically or via user intervention following a visual inspection. CNC uses LCM to alleviate congestion through Tactical Traffic Engineering (TTE) SR policies if a recommended change is approved.
Let's look at a simplified example of LCM using Tactical Traffic Engineering (TTE) SR policies. LCM analyzes the real-time topology at regular intervals. Once congestion is detected above a configured threshold, LCM will calculate how much traffic is eligible for redirection. In the example below, Node B has exceeded the monitored threshold for traffic utilization on its interface to Node C.
LCM will only redirect traffic not carried over an existing SR-TE policy. LCM looks at the amount of traffic that exceeds the user-defined utilization threshold and then calculates the amount of traffic eligible for redirection. The Total traffic minus the SR-TE Policy traffic is the amount of eligible traffic. Once the amount of traffic is determined, LCM creates multiple TTE SR policies and load balances the allotted traffic over the current shortest path B-C and the alternate path B-D-C to divert the minimum amount of traffic over the alternate path. LCM determines the number of TTE SR Policies needed and their TE paths. The amount of traffic that must be detoured vs. the amount of traffic that can remain on the IGP shortest path determines the number of policies necessary.
Controllers like CNC are sometimes referred to as Bandwidth Brokers because they can dynamically reroute traffic based on Bandwidth constraints. The second feature enhancement to SR-TE that CNC offers is Bandwidth on Demand (BWoD) which provides SR policy paths with requested bandwidth when available in conjunction with an SR Path Computation Element or SR-PCE. CNC monitors and periodically checks all specified links for congestion. If link utilization exceeds a configured user threshold, BWoD will reoptimize the SR Policy Path to conform to the specified Bandwidth requirement.
BWoD relies on standard SNMP MIBs to measure SR Policy traffic utilization and ensure that a policy with BWoD meets the specified bandwidth restrictions. Through an approximate real-time model, users may adjust the behavior of BWoD and affect the computational path by changing the network utilization threshold and the path optimization intent. If the option is enabled and, in the event BWoD cannot find the requested bandwidth for a given SR Policy path, BWoD will default to the best-effort path. If the CNC Optimization Engine becomes unavailable due to a request for a Topology rebuild or a restart of the Optimization engine, BWoD will be unavailable during this period. Any requests will be declined until the Optimization Engine comes back online.
How a BWoD SR Policy path is provisioned by the user depends on the utilization of the links in the Transport network. The CNC Optimization Engine will attempt to find a single path over underutilized links, but in some cases, that will not be achievable. In the diagram below, CNC has been instructed to find a path from A to F with a specified bandwidth.
During user provisioning, if the Optimization Engine cannot allocate the requested bandwidth over a single path, CNC will resort to multiple paths over several links to achieve the desired bandwidth. As indicated in the diagram, CNC has chosen three paths, A-D-F, A-D-C-F, and A-B-C-E-F, to fulfill the user request. If the user is satisfied with the proposed solution, he can opt to provision this new BWoD policy.
CNC is a powerful tool for automating and provisioning transport networks that also functions as a Bandwidth broker. It enhances the already robust SR-TE model by providing Local Congestion Mitigation and Bandwidth on Demand services. The utilization of CNC for these use cases enhances SR-TE making it far more flexible and attractive.
Please contact us today with any questions or details on SR-TE and CNC.