Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Guide That Contains This Content
[+] Expand All
[-] Collapse All

    NorthStar Controller Features

    The NorthStar Controller software provides traffic-engineering based solutions for WAN and Edge (data center edge and WAN edge) networks. After the NorthStar Controller has connected to the network and dynamic topology acquisition is performed to provide a real-time routing view of the network topology, you can view the network model from the NorthStar Controller user interface. You can then plan, analyze, and assess the impact of network changes you want to make before implementing them.

    The NorthStar Controller supports the following use cases and features:

    • High Availability (Active/Standby)—The NorthStar Controller High Availability (HA) implementation provides an Active/Standby solution, meaning that one node in the cluster (the active node) runs the active NorthStar components (PCE, TopoServer, Path Computation, REST), while the remaining (standby) nodes run only those processes necessary to maintain database and BGP-LS connectivity unless the active node fails.
    • Web User Interface—An alternate to the Java client method of accessing the NorthStar Controller application. Features available by way of the web UI are defined by user role (network operator or planner). The web UI is accessed through the web server URL, using a modern web browser.
    • Multilayer Support—Improves the quality of NorthStar Controller path computations by factoring in a level of information about the transport domain that would otherwise not be available. The topology information is pushed to the NorthStar Controller client in the form of a YANG-based data-model over RESTCONF and REST APIs. This ensures that the client and the transport network entity can communicate. For more information about YANG data modeling, see YANG Data Model for TE Topologies.
    • Dynamic topology acquisition—Use routing protocols (IS-IS, OSPF, and BGP-LS) to obtain real-time topology updates.
    • Label-switched path (LSP) reporting—Label edge routers (LERs) use PCEP reports to report all types of LSPs (PCC_controlled, PCC_delegated, and PCE_initiated) to the NorthStar Controller.
    • LSP provisioning—Create LSPs from the NorthStar Controller or update LSPs that have been delegated to the NorthStar Controller.
    • Bidirectional LSPs—Design a pair of LSPs so that the LSP from the ingress LER to the egress LER follows the same path as the LSP from the egress LER to the ingress LER.
    • Diverse LSPs—From the NorthStar Controller user interface, design two LSPs so that the paths are either node, link, or SRLG diverse from each other.

      Note: The NorthStar Controller supports diverse point-to-point diverse LSPs. The provisioning of diverse point-to-multipoint diverse LSPs is not supported.

    • Standby and secondary LSPs—Provide an alternate route in the event the primary route fails. The tunnel ID, from node, to node, and IP address of a secondary or standby LSP are identical to that of the primary LSP. However, secondary and standby LSPs have the following differences:
      • A secondary LSP is not signaled until the primary LSP fails.
      • A standby LSP is signaled regardless of the status of the primary LSP.
    • Time-based LSP scheduling—Schedule the creation of LSPs based on future requirements by using time-based calendaring. You can schedule an LSP as a one-time event or recurring daily event for a specified period of time to schedule setup, modification, and tear down of LSPs based on the traffic load, bandwidth, and setup and hold priority requirements of your network over time. The scheduling of an LSP is configured on the primary path, and the scheduled time applies to all paths (primary, secondary, and standby).
    • LSP templates—Create LSP templates to define a set of LSP attributes to apply to all PCE-initiated LSPs that provide a name match with the regular expression (regex) name specified in the template. By associating LSPs (through regex name matching) with an LSP template, you can automatically enable or disable LSP attributes across any LSPs that provide a name match with the regex name that is specified in the template.
    • Auto-bandwidth LSPs—Auto-bandwidth support for Path Computation Element (PCE)-controlled (PCE-initiated or PCC-delegated) LSPs—Path Computation Clients (PCCs) can automatically adjust the required bandwidth based on the traffic load on the LSP. Auto-bandwidth parameters must be configured from the PCC, even when the LSP has been delegated to the NorthStar Controller. However, you can enable auto-bandwidth parameters by way of a template so that any PCE-controlled LSP that provides a name match with a regular expression (regex) name defined in a template inherits the LSP attributes specifed in that template.

      Note: The bandwidth specified in a PCE-initiated LSP must be greater than or equal to the minimum bandwidth that is specified in an auto-bandwidth template, or the template should not contain a minimum-bandwidth clause. In addition, the bandwidth specified in a PCE-initiated LSP should not exceed the maximum bandwidth that is specified in the template.

      Auto-bandwidth behavior varies depending on the LSP type:

      • Router-controlled LSPs—The NorthStar Controller must learn about router-controlled LSPs. The PCC performs statistical accounting of LSP bandwidth and LSP resizing is driven by bandwidth threshold triggers. The NorthStar Controller is updated accordingly.
      • NorthStar Controller managed (Delegated) LSPs —The PCC performs bandwidth accounting for these LSPs. When bandwidth thresholds are reached, a PCReq message is sent to the NorthStar Controller’s Path Computation Server (PCS) to compute the Explicit Route Object (ERO). The PCC determines how to resize the LSP while the PCS provides the ERO that meets the constraints. These LSPs are delegated as usual, and PCRpt messages are sent with the Delegation bit set.

        When bandwidth threshold triggers are reached on the PCC, a PCReq message is sent to the PCE to request a path with new bandwidth. The following conditions apply:

        • If a new path is available, make-before-break (MBB) signaling is attempted and a new path is signaled. The PCRpt message from the PCC to PCE reports the updated path.
        • If a new path is not found, the process described above is repeated whenever the adjust interval timer is triggered.
      • NorthStar Controller created LSPs—When an LSP is created from the NorthStar Controller user interface, a template defines the autobandwidth attributes associated with the LSP, which allows the PCC to treat the LSP as an auto-bandwidth LSP. All other LSP behavior is the same as the NorthStar Controller managed LSP (as described above).
    • LSP optimization—Analyze and optimize LSPs that have been delegated to the NorthStar Controller. You can use the Path Analysis feature to manually trigger path optimization from the NorthStar Controller user interface or use the Path Optimization feature to automatically optimize paths based on user-defined time intervals.
    • Enable and disable LSP provisioning from the NorthStar Controller— You can enable passive monitor mode from the NorthStar Controller CLI to globally disable provisioning of LSPs for all NorthStar Controller users. You can also enable and disable LSP provisioning (locally or globally) from the NorthStar Controller user interface. A NorthStar Controller administrator can disable provisioning of LSPs for all users by navigating to the Tools > Options menu and selecting the Disable Provisioning check box. A NorthStar Controller user with full access privileges can also disable provisioning (for local user only) by navigating to the Tools > Options menu and selecting the Disable Provisioning check box.
    • Schedule maintenance events—Select nodes and links for maintenance. When you schedule a maintenance event on nodes or links, the NorthStar Controller routes delegated LSPs around those nodes and links that are scheduled for maintenance. After completion of the maintenance event, delegated LSPs are reverted back to optimal paths.
    • Run simulations for scheduled maintenance events—Run simulations from the NorthStar Controller on scheduled maintenance events for different failure scenarios to test the resilience of your network, or run simulations before the event occurs. Network simulation is based on the current network state for the selected maintenance events at the time the simulation is initiated. Simulation does not simulate the maintenance event for a future network state or simulate elements from other concurrent maintenance events. You can run network simulations based on selected elements for maintenance or extended failure simulations, with the option to include exhaustive failures.
    • TE++ LSPs—A TE++ LSP includes a set of paths that are configured as a specific container statement and individual LSP statements, called sub-LSPs, which all have equal bandwidth.

      For TE++ LSPs, a normalization process occurs that resizes the LSP when either of the following two triggers initiates the normalization process:

      • A periodic timer
      • Bandwidth thresholds are met

      When either of the preceding triggers are fired, one of the following events can occur:

      • No change is required
      • LSP splitting—add another LSP and distribute bandwidth across all the LSPs
      • LSP merging—delete an LSP and distribute bandwidth across all the LSPs

      For a TE++ LSP, the NorthStar Controller displays a single LSP with a set of paths, and the LSP name is based on the matching prefix name of all members. The correlation between TE-LSPs is based on association, and the LSP is deleted when there is no remaining TE LSP.

      Note: TE++ is supported on PCC (router) controlled LSPs and delegated LSPs, but TE++ LSPs cannot be created on the NorthStar Controller.

    Modified: 2016-04-28