NorthStar Controller: adapting to real-time traffic volumes
I previously blogged about the benefits of having a central controller, in the shape of NorthStar, in the WAN. This time I’m going to show how NorthStar can react to the changing traffic levels on an LSP, and make modifications to the path accordingly if needed. This is very useful in situations where the traffic varies as a function of time, which makes a fixed bandwidth reservation impracticable.
The screenshot below shows the network topology. NorthStar has a BGP-LS peering with Node 105. In this way, NorthStar knows the topology of the network and the TE attributes of each link, including link colors, available bandwidth, maximum reservable bandwidth, IGP metric, SRLGs and so on. You can display any/all of these attributes in the NorthStar GUI. In the screenshot on each link we show the IGP metric and maximum reservable bandwidth in each direction.
On NorthStar, via the GUI or the REST API, we instantiate an autobandwidth LSP from node 102 to node 104. The LSP is configured with a bandwidth reservation of 1 Mbps. The controller computes the shortest path (in terms of IGP metric) that meets the bandwidth requirement. The controller then sends a path setup request via PCEP to the ingress router, node 102, which then signals the LSP via RSVP along the path stipulated by NorthStar. The LSP is highlighted in yellow in the screen-shot. As you can see, it follows the path 102-105-107-104. In the "Type" column you can see that it is flagged as an autobandwidth LSP.
Now let’s see what happens when we send traffic at a rate of ~2 Gbps into the LSP. The ingress router reports this traffic level to NorthStar via PCEP. This can be seen in the screenshot below, in the bottom row of the LSP table in the “Live_BW” column. This triggers NorthStar to reassess the path of the LSP in the light of this traffic report. As you can see, the path stays the same because it can accommodate the increased traffic level. NorthStar updates the ingress router with the new bandwidth reservation value. In turn, the ingress router signals the new bandwidth reservation via RSVP along the path of the LSP. The bandwidth reservation is shown in the “BW” column of the LSP table. You can see that it is consistent with the live bandwidth that had been reported by the ingress router.
Let’s now increase the traffic to above 5 Gbps. The ingress router reports the new bandwidth level to NorthStar via PCEP. Note that the link from 102 to 105 cannot accommodate this amount of bandwidth, as the maximum RSVP reservable bandwidth is 5 Gbps. NorthStar automatically computes a new path that can accommodate the increased traffic level, and sends the new path to the ingress router via PCEP, along with the new bandwidth reservation value. As you can see in the screenshot below, NorthStar has changed the path to 102-106-105-107-104.
The screenshot below shows the history the LSP, including changes in the bandwidth reservation and the path. Also shown is a strip-chart that tracks changes in the bandwidth reservation on the LSP. This is a very convenient way of tracking how the LSP has changed over time.
Using the LSP History window, it is also possible to display the path used by the LSP at any point in the past. For example, the screenshot below shows the path of the LSP at the time denoted by the blue vertical line in the stripchart. This is a much more convenient way of visualising the LSP history than looking at router logs!
In this blog, we’ve seen how NorthStar reacts to changing traffic volumes by automatically modifying the paths of LSPs accordingly. Next time, we’ll see how we take things one step further, by enabling dynamic splitting of LSPs in order to make use of multiple pathways across the network between the ingress and egress node.