Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Provision and Manage P2MP Groups

 

Introduction

P2MP groups, or trees, can be provisioned to help conserve bandwidth. Bandwidth is replicated at branch points.

In the NorthStar Controller, you can provision P2MP groups; view and modify group attributes; and view, add, modify, or delete sub-LSPs. This is a separate workflow from provisioning P2P LSPs, and is initiated from the P2MP Group tab in the network information table.

NorthStar supports two provisioning methods for P2MP groups: NETCONF and PCEP. PCEP provisioning offers the advantage of real-time reporting. Functionality and support for the two provisioning methods are not identical; differences are noted in this documentation. For PCEP-provisioned P2MP groups, NorthStar also supports association with a multicast VPN instance (S,G) flow in its PCEP P2MP service mapping functionality. IMPORTANT: See the release notes for Junos OS release requirements related to PCEP provisioning and PCEP P2MP service mapping.

PCEP-Provisioned P2MP Groups with Service Mapping

Beginning with Junos OS Release 19.4R1, Junos OS has the ability to associate multicast flows (S,G) in the multicast VPN context to a PCEP P2MP LSP provisioned via the NorthStar Controller, in accordance with draft-ietf-pce-pcep-flowspec-05. Beginning with NorthStar Controller Release 5.1.0, you can leverage that Junos OS functionality by provisioning PCEP P2MP groups in NorthStar that you associate with one or more multicast flows (S,G) in a multicast VPN. Once a P2MP group is associated with a particular (S,G) in a multicast VPN, traffic from that particular source IP S going to group IP G, is able to utilize that particular P2MP group. It’s important to understand the effect on the flows of making various configuration changes on the router, so we recommend using your Junos OS documentation as a reference.

The NorthStar side of this functionality requires specific configuration on the router which is described in the next section.

Note

This service mapping functionality is not the same as the user properties-based service mapping that is supported for NETCONF-provisioned LSPs as described in Templates for Netconf Provisioning.

Required Router Configuration

In Junos OS Release 15.1F6 and later, you can enable the router to send P2MP LSP information to a controller (like the NorthStar Controller) in real time, automatically. Without that configuration, you must run device collection for NorthStar to learn about newly provisioned P2MP LSPs. The configuration is done in the [set protocols pcep] hierarchy for PCEs and for PCE groups. The following configuration statement allows PCEP to report the status of P2MP trees in real time, whether provisioned by NETCONF or by PCEP:

set protocols pcep pce pce-id p2mp-lsp-report-capability

For PCEP-provisioning, the following additional configuration statements are also required:

set protocols pcep pce pce-id p2mp-lsp-update-capability
set protocols pcep pce pce-id p2mp-lsp-init-capability

For PCEP P2MP service mapping with flowspec, the following additional configuration statements are also required:

To enable the router to support traffic steering (flowspec), configure the following command on the head-end:

set protocols pcep pce pce-id pce-traffic-steering

To enable the router to accept P2MP LSP provisioning with S,G for this multicast VPN from an external controller (such as NorthStar):

set routing-instances routing-instance-name provider-tunnel external-controller pccd
set routing-instances routing-instance-name protocols mvpn sender-site

The following is a sample configuration on a router with a P2MP group head end:

set protocols pcep pce pce-id p2mp-lsp-report-capability
set protocols pcep pce pce-id p2mp-lsp-update-capability
set protocols pcep pce pce-id p2mp-lsp-init-capability
set protocols pcep pce pce-id pce-traffic-steering
set routing-instances routing-instance-name routing-options static route ip-address next-hop ip-address
set routing-instances routing-instance-name routing-options multicast ssm-groups multicast-address-group
set routing-instances routing-instance-name protocols pim interface interface mode sparse
set routing-instances routing-instance-name protocols mvpn sender-site
set routing-instances routing-instance-name instance-type vrf
set routing-instances routing-instance-name provider-tunnel external-controller pccd
set routing-instances routing-instance-name provider-tunnel rsvp-te label-switched-path-template mvpn-template
set routing-instances routing-instance-name interface interface
set routing-instances routing-instance-name route-distinguisher RD
set routing-instances routing-instance-name vrf-target route-target
set routing-instances routing-instance-name vrf-table-label
set protocols mpls label-switched-path mvpn-template template p2mp
Note

After provisioning P2MP LSPs, if there is a PCEP flap, the UI display for RSVP utilization and RSVP live utilization might be out of sync. This is also true for P2P LSPs. You can display utilization metrics by navigating to Performance in the left pane of the UI. This is a UI display issue only. The next live update from the network or the next manual sync using Sync Network Model (Administration > System Settings > Advance Settings) corrects the UI display. In the System Settings window, you toggle between General and Advanced Settings using the button in the upper right corner of the window.

Useful Junos OS show Commands

Table 1 includes some useful Junos OS commands and what the output can show you.

Table 1: Useful Junos OS show Commands

Junos OS Command

Purpose

show mpls lsp p2mp ingress extensive

Provides details of each of the sub-LSPs that belong to P2MP groups.

show path-computation-client lsp

Provides information about LSPs, including their status and type.

show rsvp session p2mp ingress statistics

Provides information to confirm whether the selective tunnel is taking precedence over the original inclusive dynamic provider tunnel as expected. Only useful when traffic is flowing.

show mvpn c-multicast instance-name mvpn-instance-name display-tunnel-name

Displays which P2MP group is mapped to which S,G within a multicast VPN.

show path-computation-client traffic-steering

Displays all P2MP groups with flowspec ID, state, and (S,G) prefix.

Automatic Rerouting Around Points of Failure

For PCEP-provisioned P2MP groups only (including those with flow-mapping information), sub-LSPs are dynamically rerouted around points of failure along the path of the tree. You should not necessarily expect to see the Op Status in the network information table change during the re-route because it happens very quickly. The topology map displays a red F on any failed link or node, and you can see how the path is rerouted around those markers.

View P2MP Groups and Their Sub-LSPs

P2MP group information is displayed in the P2MP Group tab of the network information table, and is also reflected in the topology map.

Note

When changes have been made, but are not yet reflected in the UI, click the refresh button at the bottom of the network information table to update the UI.

To display P2MP Group information, use the following steps:

  1. On the tabs bar of the network information table, click the plus sign (+) and select P2MP Group from the drop-down menu as shown in Figure 1.Note

    When you launch the web UI, only the Node, Link, and Tunnel tabs are displayed by default; P2MP Group is one of the tabs you can optionally display.

    Figure 1: Adding the P2MP Group Tab
    Adding
the P2MP Group Tab
  2. The P2MP Group tab is added to the tab bar and the contents are displayed as shown in Figure 2.
    Figure 2: P2MP Group Tab in the Network Information Table
    P2MP Group Tab in the Network
Information Table

    Columns for group attributes are shown across the top. You can add columns and filter the display in the usual ways. See Sorting and Filtering Options in the Network Information Table for more information.

  3. Click a row in the table to highlight the path in the topology map.
  4. Right-click a row in the table to display either a graphical tree view of the group, the flows associated with the group, or a list of the sub-LSPs that make up the group. Figure 3 shows these options.
    Figure 3: Right-Click a P2MP Group
    Right-Click a P2MP
Group

    The tree diagram opens as a separate pop-up as show in Figure 4.

    Figure 4: P2MP Group Graphical Tree Diagram
    P2MP Group Graphical Tree Diagram

    When you select to view sub-LSPs, the sub-LSPs that make up the group are displayed in a new tab in the network information table. On the list of sub-LSPs, you have all the display options normally available on the Tunnel tab. See Network Information Table Overview for more information.

    Note

    The sub-LSP tab in the network information table is for display purposes only; you cannot perform Add, Modify, or Delete functions from there. But the sub-LSPs are also displayed in the Tunnel tab, where you can perform those actions.

In the P2MP Group tab of the network information table, the Control Type column displays Device Controlled for NETCONF-provisioned groups and PCEInitiated for PCEP-provisioned groups.

Note

NETCONF-provisioned P2MP group configuration statements can be viewed in the router configuration file. To view PCEP-provisioned P2MP group configuration, you must use the Junos OS command run show mpls lsp p2mp in operational mode because the LSPs are PCE-initiated.

Add a P2MP Group

On the P2MP Group tab of the network information table, click Add at the bottom of the table. The Add P2MP Group window is displayed as shown in Figure 5. Red asterisks denote required fields.

Figure 5: Add P2MP Group Window, Properties Tab
Add P2MP Group Window,
Properties Tab

Table 2 describes the data entry fields in the Properties tab of the Add P2MP Group window.

Table 2: Add P2MP Group Window, Properties Tab Fields

Field

Description

P2MP Name

Required. A user-defined name for the P2MP group. Only alphanumeric characters, hyphens, and underscores are allowed. Other special characters and spaces are not allowed.

ID Prefix

You can enter a prefix to be applied to all of the tunnel names that are created.

Bandwidth

Required. Planned bandwidth immediately followed by units (no space in between). Valid units are:

  • B or b (bps)

  • M or m (Mbps)

  • K or k (Kbps)

  • G or g (Gbps)

Examples: 50M, 1000b, 25g.

If you enter a value without units, bps is applied.

Provisioning Type

The default is RSVP, which is the only option supported for P2MP groups. As of this release, even if you select SR, RSVP is used.

Setup

Required. RSVP setup priority for the tunnel traffic. Priority levels range from 0 (highest priority) through 7 (lowest priority). The default is 7, which is the standard MPLS LSP definition in Junos OS.

Hold

Required. RSVP hold priority for the tunnel traffic. Priority levels range from 0 (highest priority) through 7 (lowest priority). The default is 7, which is the standard MPLS LSP definition in Junos OS.

Provisioning Method

Use the drop-down menu to select PCEP or NETCONF. The default is NETCONF.

Node A

Required. The name or IP address of the source node. Select from the drop-down list.

Node Z

At least one is required. The names or IP addresses of the destination nodes. To select nodes from the topology map, Shift-click the nodes on the map and then click the world button at the bottom of the Node Z field. To add all nodes in the network, click the plus (+) button. To remove a node, highlight it in the Node Z field and click the minus (-) button.

The Advanced tab includes the fields shown in Figure 6 and described in Table 3.

Figure 6: Add P2MP Group Window, Advanced Tab
Add P2MP Group Window, Advanced
Tab

Table 3: Add P2MP Group Window, Advanced Tab Fields

Field

Description

Bandwidth Sizing

Controls whether bandwidth sizing is enabled for the P2MP group. Use the drop-down menu to select yes or no. The default is no.

Coloring Include All

Double click in this field to display the Modify Coloring Include All window. Select the appropriate bits. Click OK when finished.

Coloring Include Any

Double click in this field to display the Modify Coloring Include Any window. Select the appropriate bits. Click OK when finished.

Coloring Exclude

Double click in this field to display the Modify Coloring Exclude window. Select the appropriate bits. Click OK when finished.

Diversity Group/Level

Diverse P2MP is currently not supported via the web UI, so these fields are not used. Diverse P2MP computation via REST API is currently available for NETCONF P2MP groups, but not for PCEP P2MP groups.

Comment

Free-form comments if needed.

The Design tab includes the Routing Method options shown in Figure 7.

Figure 7: Add P2MP Group Window, Design Tab
Add P2MP Group Window, Design
Tab

For NETCONF-provisioned P2MP, the default routing method is routeByDevice (since it uses NETCONF as the provisioning method). You can select a different routing method in which the PC server calculates the path for all the sub-LSPs. For PCEP-provisioned P2MP, select default as the routing method. The routeByDevice routing method is not available for PCEP-provisioned P2MP because an empty ERO would be sent. The behavior for all routing methods is similar to P2P LSP provisioning.

Note in Figure 7 that the Service Mapping tab is grayed out. That’s because the provisioning method selected was NETCONF in order to display all the possible routing methods. The Service Mapping tab is only available for PCEP provisioning.

When the provisioning method selected is PCEP, the Service Mapping tab is available. It includes the fields shown inFigure 8 and described in Table 4.

Figure 8: Add P2MP Group Window, Service Mapping Tab
Add P2MP Group Window,
Service Mapping Tab

Table 4: Add P2MP Group Window, Service Mapping Fields

Field

Description

MVPN Instance

Multicast VPN instance as configured on the router.

RD

Router distinguisher (RD).

The RD poulates automatically when you select the multicast VPN instance, if the information is available. If the field does not automatically populate, you can:

  • Obtain the RD from the head-end router configuration.

  • Run device collection for the head-end router from the Node tab of the network information table. Right-click on the head-end router and select Run Device Collection. Once the collection completes, the RD field should auto-populate.

Flows

In the Flows table, you define the S,G groups. For each flow you want to add, click the + button to display a new line.

To add the flows, you must manually type the source IP address and mask, and the Group IP address (multicast traffic destination) and mask. You can either point and click or tab between fields.

The maximum number of flows (S,G groups) that you can successfully associate with a P2MP LSP depends on a few parameters such as the traffic rate and group type (SSM or ASM), and is therefore, not a concrete number.

If you surpass the maximum number of flows for the P2MP group, all the flows go into “Inactive (mapping successful)” state as viewed in the output of the show path-computation-client traffic-steering command on the router. To recover, delete the entire group and recreate it.

The Scheduling tab is identical to the one you use to provision P2P LSPs and is shown in Figure 9.

Figure 9: Add P2MP Group Window, Scheduling Tab
Add P2MP Group Window,
Scheduling Tab

Select Once to set up start and end parameters for a single event. Select Daily to to set up start and end parameters for a recurring daily event. Click the calendar icon beside the fields to select the start and end dates, and beginning and ending times. At the scheduled end time, the group is torn down.

You can view the progress of scheduled P2MP groups in the Tunnel tab of the network information table, using the Op Status and Controller Status columns as shown in Table 5.

Table 5: Op Status and Controller Status for Scheduled P2MP Groups

Event

Op Status

Controller Status

P2MP group is scheduled; activation time is in the future

“Unknown”

“Callsetup_Scheduled” with the activation time in parentheses

Scheduled window for the P2MP group begins

“Active”

“Disconnect_Scheduled” with the disconnection time in parentheses

Scheduled window for the P2MP group ends

“Unknown”

“Time_Expired”

Figure 10 shows an example of the network information table Tunnel tab with scheduled tunnels in progress, expired, and pending. Note the Op Status and Controller Status columns.

Figure 10: Tunnel Tab with Scheduled Tunnels
Tunnel Tab with Scheduled
Tunnels

The tunnels remain in the Tunnel tab, even after the scheduled window has ended. This allows you access to historical data about when LSPs were scheduled and torn down. You can filter the Time_Expired tunnels out of your display using either the Filter function at the bottom of the network information table (magnifying glass icon), or the column filtering function available when you right-click in a column heading. See Network Information Table Bottom Tool Bar and Sorting and Filtering Options in the Network Information Table to see how these filtering options work.

Note

Time_Expired P2MP groups remain visible in the P2MP Group tab of the network information table.

The User Properties tab is used for P2MP group to multicast VPN service mapping (not supported for PCEP-provisioned P2MP groups). See Templates for Netconf Provisioning for more information.

Once you are finished defining the group, click Submit. The group is added to the network information table, on the P2MP Group tab.

Note
  • Naming of the sub-LSPs is automatic, based on the Prefix-ID if provided, and the A and Z node names.

  • For NETCONF-provisioning, if the routing method is routeByDevice, the path for all sub-LSPs is dynamic. For any other routing method, the path is preferred. This can be changed for individual sub-LSPs.

  • Do not change the routing method for PCEP-provisioned sub-LSPs; they should always have a routing method of “default”.

Modify a P2MP Group

To modify a P2MP group, select the group in the P2MP Group tab of the network information table, and click Modify at the bottom of the table. The Modify P2MP Group window is displayed as shown in Figure 11.

Figure 11: Modify P2MP Group Window, Properties Tab
Modify P2MP Group
Window, Properties Tab
Note

The Service Mapping tab is only displayed if you are modifying a PCEP-provisioned P2MP group with service mapping.

Using the tabs on the Modify P2MP Group window, you can change the value of attributes (affects all sub-LSPs in the group), add or remove destination nodes (which adds or removes sub-LSPs), and set up or change scheduling for the group. For PCEP P2MP groups with service mapping, you can also use the Service Mapping tab to add or change flows.

To remove sub-LSPs from a group, select the destination node(s) in the Node Z field (Properties tab of the Modify P2MP Group window), and click the minus sign (-). If you remove a sub-LSP from a PCEP P2MP group with service mapping, the mapping remains intact and the tunnel continues to carry traffic.

Note

You could also remove sub-LSPs using the Tunnel tab of the network information table. Select the sub-LSP to be removed and click Delete at the bottom of the table.

When you have finished making changes, click Submit.

Note

The following six attributes must be the same for all sub-LSPs in a P2MP group, and can therefore only be modified at the group level, using the Modify P2MP Group window:

  • Bandwidth

  • Setup

  • Hold

  • ColoringIncludeALL (cannot be modified for PCEP-provisioned groups in this release)

  • ColoringIncludeANY (cannot be modified for PCEP-provisioned groups in this release)

  • ColoringExclude (cannot be modified for PCEP-provisioned groups in this release)

You can modify other attributes on the individual sub-LSP level (path or Max Hop, for example). To modify sub-LSP attributes, select the tunnel in the Tunnel tab of the network information table and click Modify at the bottom of the table. If you attempt to modify one of the six group-level-only attributes at the sub-LSP level, an error message is displayed when you click Submit and the change is not made.

Note

If the sub-LSPs tab in the network information table fails to update after modifying group or sub-LSP attributes, you can close the sub-LSPs tab and reopen it to refresh the display. There is also a refresh button at the bottom of the table that turns orange when prompting you for a refresh. When you click the refresh button, the web UI client retrieves the latest P2MP sub-LSP status from the NorthStar server.

Delete a P2MP Group

When you delete a P2MP group, all sub-LSPs that are part of that group are also deleted. If you delete a P2MP group with associated multicast flows (S,G) in a multicast VPN context, the flows are also deleted.

To delete a P2MP group, select the group on the P2MP Group tab of the network information table and click Delete at the bottom of the table. Respond to the confirmation message to complete the deletion.

Alternatively, you can use the Tunnel tab of the network information table to delete all the sub-LSPs in the P2MP group, which also deletes the group itself.

P2MP Tree Design with Diverse PE to CE Links

NorthStar Controller can calculate diverse P2MP tree designs all the way to a customer edge (CE) node or site. Although the path computation extends to the intended endpoints (the CE nodes or sites), the sub-LSPs actually terminate on the provider edge (PE) nodes. This ensures that the selection of tail nodes best satisfies the diversity constraints. When the diverse P2MP trees are computed, NorthStar considers the shared risk groups and affinity constraints in the PE-CE links.

Figure 12 shows an example topology that could leverage this type of P2MP tree design. Two data sources are located at PE nodes PE1 and PE2. The receiving nodes are located in sites A, B, C, and D, each site having two CE nodes.

Figure 12: P2MP Tree Design with Diverse PE to CE Links Example Topology
P2MP Tree Design with Diverse
PE to CE Links Example Topology

Calculating pairs of diverse P2MP LSPs that terminate in the same nodes or sites would enable the two data sources to distribute redundant data streams to the CE nodes/sites.

Sites A, B, C, and D could also be depicted as shown in Figure 13, where each site is shown as a pseudo-node. In this context, a pseudo-node is any node or site not discovered or managed by NorthStar. The pseudo-nodes can be used as the leaf nodes in tree calculations.

Figure 13: Diverse PE to CE Links Topology with Pseudo-Nodes
Diverse PE to CE Links
Topology with Pseudo-Nodes

The goal is for each sub-LSP in a diverse pair to be routed over a different PE-CE link, transiting a different PE node. Each sub-LSP terminates on the PE node that is the penultimate hop to the destination. An example is shown in Figure 14. The redundant data streams are represented by the two colored paths.

Figure 14: Diverse PE to CE Links Topology with Redundant Data Streams
Diverse PE to CE Links
Topology with Redundant Data Streams

You request a tree design with diverse PE to CE links through the REST API. When the tree is created, the ERO of the route is always strict. This is in contrast to a single P2MP group in which a loose path to the address can be specified. The result is that if a link goes down in a diverse P2MP tree, the signaling address remains the same and the operational status of the tunnel remains down. If the link comes back up, the tunnel is restored. Or you could delete the tunnel and schedule a new one.

The PCS follows a set of rules when routing LSPs to CE nodes or sites:

  • The links connecting to the CE nodes or sites might not have protocols enabled since they do not need to support LSPs. But the PCS must still consider those links for path placement.

  • The PCS will not ever use a pseudo-node marked as an Access node as a transit node. Access nodes are end destination nodes.

  • LSPs to CE nodes or sites must be signaled to their penultimate hop, the final PE in the path.

  • The ERO pushed to the devices must be trimmed so it does not include the pseudo-node addresses or the PE-CE link identifiers.

NorthStar cannot discover CE nodes and sites, so you must add them and their associated links to the topology, using either the UI or the REST API.

Adding CE Nodes/Sites and Links Using the UI

In the network information table, Node tab, click Add in the bottom tool bar. The Add Node window is displayed as shown in Figure 15. At this time, this window is exclusively for adding CE nodes/sites as opposed to other node types. These nodes/sites are used for path computation, but not for signaling. The data entry fields are described in Table 6 and Table 7.

Figure 15: Adding a CE Node
Adding a CE Node

Table 6: Add Node Window: Properties Tab Field Descriptions

Field

Description

Name

Required. Name for the node/site.

IP Address

IP address for the node/site.

Comment

Free-form text.

IP Role

Use the drop-down menu to select:

  • Regular for nodes that can be used for transit purposes.

  • Access for nodes/sites that are end destinations. These nodes/sites cannot be used for transit purposes.

  • Core for nodes that can be transit nodes but cannot terminate LSPs from access nodes directly. This option is reserved for future use and is not relevant to P2MP tree designs with diverse PE to CE links.

Node Type

Select the radio button for either CE or Site. The selection depends on your network topology. In some networks, the termination is on a CE node. In others, the termination is on a network beyond the CE, which would be considered a site. Nodes and sites are depicted differently in the NorthStar topology map.

Table 7: Add Node Window: Addresses Tab Field Descriptions

Field

Description

Longitude

Longitude of the endpoint.

Latitude

Latitude of the endpoint.

Site

Geographical site to which the node belongs, if any. You can use specification of a geo-site to group tagged nodes in the UI.

Figure 16 shows a sample topology with some CE nodes that are configured as Regular and others that are configured as Access. For example, nodes CE_A1 and CE_B1 are Regular nodes because they need to be used for transit to the alpha and beta sites respectively. CE_D1 and CE_D2 are examples of Access nodes that represent end points, and are not used for transit purposes.

Figure 16: Sample Topology with Access and Regular Pseudo-Nodes
Sample Topology with Access
and Regular Pseudo-Nodes

In addition to creating the nodes, you must also add links between the CE nodes/sites and the PE nodes in the topology, using the Add Link window accessible from the network information table bottom tool bar. Because the nodes are pseudo-nodes, the links connecting them are pseudo-links. As pseudo-links, their status will remain Unknown in the Status column of the network information table (Link tab).

Special Notes for the Current NorthStar Release

The following notes apply to the current NorthStar release:

  • Hybrid diverse P2MP groups (destination designation includes both PEs and CEs) is not supported.

  • You cannot provision diverse P2MP trees using the NorthStar UI. It must be done through the REST API.

  • Diverse P2MP with flow mapping is not supported. The workaround for this limitation is to create a diverse tree using the REST API and then assign mapping to individual P2MP groups either using the UI or the REST API.