Juniper NorthStar SD-WAN – Network Wide Visibility

The source for this blog post is taken from Ivan Pepelnjak’s Software Gone Wild Podcast on NorthStar_MPLS-TE_Controller.

 

The Challenge

Existing service provider challenges include lack of visibility into customers traffic. They are often not aware of the granular details of traffic profiles, which leads them to over-provision bandwidth and link resilience. There are a vast amount of over-provisioned networks. Upgrades at both a packet and optical layer occur without full traffic visibility and justification. Many core networks are left at half capacity just in case there is a spike. Money is wasted on underutilisation, that could be spent on product and service innovation.

There are many reasons why you might need the analytical information, not just for bandwidth provisioning. A popular network analytic capability tool is sFlow and NetFlow. Nodes capture and send sFlow information to an sFlow collector where the operator can analyze with graphing and analytical tools of an sFlow collector. An additional tool that can be used is a centralized SDN controller that can analyze the results and make necessary changes to the network in a programmatic way. A centralized global viewpoint can aid in making intelligent multi-domain Traffic Engineering (TE) decisions.

 

Traffic Engineering

Traffic engineering allows packets to be forwarded over non-shortest paths. Tools such as Resource Reservation Protocol (RSVP) and Fast Re-Route (FRR) enhance the behavior of TE. IGP-based TE uses a distributed routing protocol to discover the topology and run algorithms to discover the shortest path. MPLS/RSVP-TE provides enhancements to standard TE and allows more granular forwarding control and ability to differentiate traffic types for CoS/QoS purposes. A shortest path algorithm called Constrained Shortest Path First (CSPF) provides the ability for label switch paths (LSP) to take any available path in the network. The MPLS control plane is clearly distributed and requires a distributed IGP and label allocation protocol. The question is whether a centralized controller can solve existing traffic engineering problems? It will certainly make orchestrating a network easier.

The contents of a TED has IGP scope domain visibility. Certain applications for TE purposes requires domain-wide visibility in order to make optimal TE decisions. The IETF has defined the Path Computation Element (PCE) that is used to compute end-to-end TE paths. Link and TE attributes are shared with external components. Juniper has an SD-WAN product, called NorthStar that adopts these technologies promising network-wide visibility and enhanced TE capabilities. 

 

NorthStar SD-WAN Controller

NorthStar is a new SD-WAN product by Juniper, aimed at Service Providers and large enterprises that follow the service provider model. It is geared for the large network that have ownership of Layer 2 links. NorthStar is basically an SD-WAN Path Computation Engine (PCE), as defined in RFC 5440, that learns network state by Path Computation Element Protocol (PCEP). It provides centralized control for path computation and TE purposes, enabling you to run your network in a more optimized fashion. NorthStar gives you a programmable network with global visibility. Allowing you to spot problems and deploy granular control over traffic.

Juniper Northstar2

 

They provide a simulation environment where they learn about all the traffic flows on the network. This allows you to simulate what “might” happen in certain scenarios. Now, with a centralized view of the network, they can optimize flows throughout the network; enabling a perfectly engineered and optimized network. The controller is able to find the extra and unused capacity, allowing the optimization of underutilized spots in the network. The analytics provided is helpful for forecasting and capacity planning. It has an offline capability providing offline versions of your network with all its traffic flows.

It takes inputs from 1) the network to determine the topology and view link attributes, 2) human operators, and 3) requests by Northbound REST API. From these inputs it make decisions about TE capabilities, more specifically where to place TE LSP in the network. It can modify LSP and create new ones, optimizing the network traffic engineering capabilities.

 

Understand Network Topology

Traditional networks commonly run IGP and build topology tables. It can get over complicated when you have a multi-area or multi IGP running on the network. NorthStar recommends BGP-LS. BGP-LS enables routers to export the contents of the TE database to BGP. It uses a new address family allowing BGP to carry node and link attributes (metric, max amount of bandwidth, admin groups and affinity bits) related to TE.  

BGP-LS can be used between different regions. As its base is BGP you can use the scalable and high available features, such as route reflection to design your BGP-LS network. While BGP is very scalable, its main advantage here is reduced network complexity. While NorthStar can peer with existing IGP (OSPF and ISIS), BGP-LS is the preferred method. Knowing the topology and attributes, the controller can setup LSP, for example, if you want diverse LSP, then it can perform a diverse LSP path computation. 

 

LSP & PCEP

There are three main types of LSP’s in a NorthStar WAN controlled network. The first is a Vanilla type LSP. It is a standard LSP, configured on ingress router and signaled by RSVP. The second is a delegated LSP, configured on ingress router but then delegated to the controller. The controller is authorized to make changes to this LSP. The third LSP is initiated by the controller itself via a human operation via GUI or Northbound API.

 

It uses a PCEP protocol, which then triggers the ingress router to setup RSVP.

 

PCEP (Path Computation Elements Protocol) provides communication between all nodes and the controller. It is used to setup and modify LSP and enable dynamic and inter-area as well as inter-domain traffic engineered path setup. It consists of two entities, PCE and PCC. Path Computation Client (PCC) and Path Computation Element (PCE) gets established over TCP. Once the session is established, PCE builds the topology database (TED) using underlying IGP or BGP-LS. BGP-LS has enhanced TLV capabilities have been added for PCE to learn/build this database. RSVP is still used to signal the LSP.

 

 

 

 

About Matt Conran

Matt Conran has created 184 entries.

Leave a Reply