Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
ON THIS PAGE
 

Multilayer Feature Overview

The multilayer feature enables NorthStar Controller to receive an abstracted view of an underlying transport network and utilize the information to expand its packet-centric applications. NorthStar Controller does not use the information to compute paths for the transport domain. The transport layer topology information comes in the form of a YANG-based data model over southbound RESTCONF and REST APIs.

The following sections describe how multilayer support is integrated into the NorthStar Controller:

Supported Interface Standards

NorthStar currently supports the following interface standards:

The NorthStar user interface for configuring and working with transport domain data and the work flow are the same, regardless of the interface standard. There are, however, a few differences in terms of supported features, and those are noted in the documentation.

Key Features of NorthStar Controller Multilayer Support

The following features apply to NorthStar Controller multilayer support:

  • A single instance of NorthStar Controller (or multiple NorthStar Controller instances deployed as a high availability cluster) can receive abstract topology information from multiple transport controllers simultaneously.

  • You can configure multiple devices associated with a single transport controller, and at least one device is required. If multiple devices are configured, NorthStar Controller attempts connection to them in round-robin fashion.

  • The transport controller should provide the NorthStar Controller with the local and remote identifier information for each interlayer link. If the transport controller is not able to provide the interlayer link identifiers on the packet domain side, it provides open ended interlayer links that you can complete using the NorthStar Controller Web UI.

  • Juniper Networks provides an open source script to be used optionally for configuring interlayer links.

  • Transport link failures can be reported by transport controllers and are displayed in the NorthStar Controller UI as failed transport links. Only failures reported in the traffic engineering database (TED) are taken into account for rerouting. IP links associated with transport link failures reported by a transport controller are not considered down by NorthStar Controller unless reported down in the TED.

  • Transport controller profile configuration can be done in the NorthStar Controller Web UI or directly via the NorthStar Controller’s northbound REST API. You can view and manage transport layer elements in both the web UI and the NorthStar Planner.

  • The web UI and the northbound REST API offer premium delay-related path design options for transport links. In the web UI, navigate to Applications>Provision LSP, and click the Design tab. These options are also available in the NorthStar Planner.

    When the transport domain is known, the delay information does not need to be populated manually or imported from a static file because the information is learned dynamically by NorthStar Controller.

  • Once the interlayer links mapping is completed, the data used by the path design options (delay, SRLGs, Protected) is populated automatically and updated dynamically through communication between the transport and NorthStar controllers.

SRLGs

NorthStar Controller considers transport shared risk link group (SRLG) information whenever a path optimization occurs or whenever some event triggers rerouting.

By default, NorthStar Controller associates transport SRLGs to IP links based on information received from the transport controller. Connecting NorthStar Controller to more than one transport controller introduces the possibility of overlap of SRLG ranges, which might not be desirable. The configuration of transport controller profiles in the NorthStar Controller Web UI allows for the specification of an additional TSRLG prefix (a prefix extension) for each transport controller to prevent unintentional overlap.

Preventing unintentional SRLG range overlap requires particular vigilance when you have transport controller ranges and you also manually assign SRLGs to IP links in NorthStar Controller.

Maintenance Events

You can schedule maintenance events for network elements (nodes, links, or facilities), so that you can perform updates or other configuration tasks.

A maintenance event is a planned downtime which occurs at a scheduled future date and time. During a scheduled maintenance event, the selected elements are considered logically down, and Paragon Automation reroutes the LSPs around those elements.

Note:

Paragon Automation only attempts to reoptimize PCE-initiated and PCC-delegated LSPs (not PCC-controlled LSPs). PCC-controlled LSPs are not rerouted to avoid scheduled maintenance events.

The maintenance event that you add is listed under the Maintenance tab on the Topology page. You can view the progress of the maintenance event from its status. A maintenance event can have one of the following status:

  • Planned—Event is scheduled some time in the future.

  • Completed—Event is completed.

  • In Progress—Event is in progress.

  • Canceled—The scheduled event has been canceled.

After the maintenance event is completed, by default, all LSPs that were affected by the event are optimized again and several maintenance reports are generated that can be viewed from Reports > Maintenance > Report-Name page.

You can view, add, simulate, edit, cancel, or delete the scheduled maintenance events for network elements from the Maintenance tab of the network information table (Network > Topology). Hover over the More Tabs list and select Maintenance. When a network element (node, link, or facility) is undergoing a maintenance event, it appears on the topology map with an red M (for maintenance).

Note:

You cannot delete a maintenance event that is in progress. You can, however, cancel one. You might want to cancel an event rather than delete it if you think you will reactivate it later, possibly with modifications.

Latency

Note:

Latency information is not available from proNX Optical Director.

NorthStar Controller can dynamically learn latency information for transport links and interlayer links, to support latency-based routing constraints for packet LSPs. There are three possible sources for latency values. All of the values are collected and saved, but when multiple values are present for the same object, the NorthStar Controller can only accept one. The NorthStar Controller resolves conflicts by accepting latency values according to their source in the following order of preference:

  • Manual configuration by the user

  • Probes on the routers that support analytics

  • Transport controller

SRLG Diverse LSP Pairs

In the web UI, you can create LSP pairs that are SRLG-diverse to each other. Use the same processes and UI windows you use to create other diverse LSP pairs, and specify SRLG for diversity. This functionality is also available in the NorthStar Planner.

Protected Transport Links

NorthStar supports preferred protected links routing constraint for packet LSPs. When this constraint is selected, NorthStar computes the path that maximizes the number of protected links, and therefore offers the best overall protection. Protected links can be implemented by way of REST APIs or using the web UI. In the web UI, navigate to Applications > Provision LSP, and click the Advanced tab. By default, the Route on Protected IP Link option is not selected.

Note:

You can also access the Provision LSP window from the network information table. From the Tunnel tab, click Add at the bottom of the table.

Related Documentation