Cisco Prime Provisioning API Programmer Guide, 7.2

Supported MPLS-TP Features

Prime Provisioning supports the following MPLS-TP features:

• MPLS-TP Discovery Tasks

– Full Discovery

– MPLS Label Sync

• MPLS-TP Policies

– Create MPLS-TP Policy

– Modify MPLS-TP Policy

– Delete MPLS-TP Policy

• MPLS-TP Service Requests

– Create MPLS-TP Tunnel

– Modify MPLS-TP Tunnel

– Delete MPLS-TP Tunnel.

API XML examples for the above operations are contained in the Cisco Prime Provisioning API 7.2 Programmer Reference.

Note It is possible to include or exclude mutipe nodes through the API when modifying an MPLS-TP service request. See example under Service Request Examples.

Policy Example

The following is an example of how to create an MPLS-TP policy with path protection. Path protection for the MPLS-TP Tunnel is enabled by setting the protectedTpTunnel variable to TRUE and setting the diversityOption to any of the three options from valueMap below, in this example Node Diversity Desired.

Example: CreateMplsTpPolicy.xml

Related APIs

• ModifyMplsTpPolicy.xml

MPLS-TP Discovery Example

The following is an example of how to create an MPLS-TP Discovery task.

The relevant attributes that need to be set for this policy are highlighted in bold in the example. In this case, it is the attribute Subtype, which in the example is set to TP_DISCOVERY.

If the item labelSyncOnly is set to true, only the label information gets discovered. In the example below, it is set to false, in which case Prime Provisioning performs a complete MPLS-TP discovery.

Example: CreateTaskServiceOrderTpDiscovery.xml

Typical Sequence of Calls

Once you have run Collect Config and MPLS-TP Discovery, the typical sequence of calls for MPLS-TP would be:

1. Associate devices with corresponding roles

2. Create MPLS-TP Policy (CreateMplsTpPolicy.xml)

3. View MPLS-TP Policy Response

4. Create Mpls MPLS-TP service request

using either

– CreateMplsTpTunnelServiceRequestWithProtection.xml—creates an MPLS-TP tunnel between tp-device1 and tp-device2 with both working and protect LSPs

or

– CreateMplsTpTunnelServiceRequestNoProtection.xml—creates an MPLS-TP tunnel with just a working LSP, no protect LSP

5. Create Mpls MPLS-TP service request Response

6. Deploy SR(Same XML as other service request types)

7. Modify MPLS-TP service request (ModifyMplsTpTunnelServiceRequest.xml).

Service Request Examples

The following XML examples illustrate how you work with service requests for MPLS-TP APIs. They also demonstrate the kinds of properties (attributes) that need to be specified for each request.

This section contains the following examples:

• Creating an MPLS-TP Service Request With Path Protection
• Modifying an MPLS-TP Service Request
• Modifying an MPLS-TP Protect Path Service Request
• Modifying an MPLS-TP Service Request with Include/Exclude Multiple Nodes

Creating an MPLS-TP Service Request With Path Protection

The following is an example of how to create an MPLS-TP service request with path protection. Protection path for TP Tunnel is enabled by setting the protectedTpTunnel variable to TRUE and selecting the diversityOption among any of the 3 options from valueMap below.

Example: CreateMplsTpTunnelServiceRequestWithProtection.xml

Modifying an MPLS-TP Service Request

The following is an example of how to modify an MPLS-TP service request. This is done by modifying the service data using the attribute LocatorId, which in the example is set to 194.

Example: ModifyMplsTpTunnelServiceRequest.xml

Related APIs

• CreateMplsTpTunnelServiceRequestNoProtection.xml
• DecommisionMplsTpTunnelServiceRequest.xml

Modifying an MPLS-TP Protect Path Service Request

In this example, an existing MPLS-TP protect path is modified without impacting the working path. The important attribute is ModifyPath, which needs to be set to Protect.

You can also do the opposite and modify the working path without impacting the protect path. In that case, the ModifyPath attribute needs to be set to Working. The ModifyPath attribute can also be set to Both.

Note The "ModifyPath" attribute is supported only when modifying MPLS-TP service requests, not when creating new MPLS-TP service requests.

Example: ModifyMplsTpTunnelServiceRequest-ProtectPath.xml

Modifying an MPLS-TP Service Request with Include/Exclude Multiple Nodes

In this example is shown how an existing MPLS-TP service request is modified to include or exclude multiple nodes.

The appropriate ID needs to be provided in the multiple group tags in the Review Routing section below (see XML example). The XML must have a unique ID in the group tag, for example pathOptionsGroup, pathOptionsGroup1, pathOptionsGroup2, etc. If you want to modify a few specific constraints amongst the ones originally provided, you need to provide the appropriate ID. For example, specify pathOptionsGroup to edit 1st constraint, pathOptionsGroup4 to edit 5th constraint and so on.

Make sure to set the ModifyPath attribute (Working, Protect, or Both).

Note The "ModifyPath" attribute is supported only when modifying MPLS-TP service requests, not when creating new MPLS-TP service requests.

Example: ModifyMplsTpServiceRequestWithIncludeExcludeNodes.xml

Process Summary

This MPLS-TP provisioning example documents the following process:

1. Create provider.

2. Create region for provider.

3. Run Collect Config.

4. Create and run MPLS-TP Discovery task.

5. Create service definition (policy).

6. Create tunnel service request.

Provisioning Process

To provision MPLS-TP using Prime Provisioning APIs, a MPLS-TP service definition (policy) and a MPLS-TP service request are required.

This section describes the process for provisioning MPLS-TP using XML examples.

The complete package of XML examples for MPLS-TP is available here:
Cisco Prime Provisioning API 7.2 Programmer Reference

Note For clarity, this provisioning process shows each step as a separate XML request. Many of these steps can be combined using performBatchOperations.

Step 1 Create a provider.

The provider is the administrative domain of an ISP, with one BGP autonomous system (AS) number. The network owned by the provider is called the backbone network. If an ISP has two AS numbers, you must define it as two provider administrative domains.

XML Examples:

ISCProviderCreateRequest.xml

Step 2 Create regions.

Each provider can contain multiple regions.

XML Examples:

ISCDefaultRegionCreateRequest.xml

Step 3 Run a Collect Config task.

A device configuration collection is a task. This task uploads the current configuration from the device to the Prime Provisioning database. The collection task is executed through a service request, and the service request is scheduled through a service order.

Note The service request name must be unique for each API.

XML Examples:

• CreateTaskServiceOrderCollection.xml

Step 4 Run an MPLS-TP Discovery task.

This discovers the MPLS-TP topology and resources and populates the repository.

XML Examples:

CreateTaskServiceOrderTpDiscovery.xml

Step 5 Create service definition (policy).

Service definitions or policies are used to define common tunnel attributes.

XML Examples:

CreateMplsTpPolicy.xml

Step 6 Create service request.

An MPLS-TP service request applies the service definition and assigns interfaces and attributes.

Tip Record the LocatorId value from the XML response for the service request. The Locator ID is required for subsequent service request tasks.

XML Example:

CreateMplsTpTunnelServiceRequestWithProtection.xml

Auditing Service Requests

There are currently two kinds of audit that can be applied to an MPLS-TP service request:

• Config Audit
• Functional Audit

Config Audit

A configuration audit occurs automatically each time you deploy a service request. During this configuration audit, Prime Provisioning verifies that all Cisco IOS commands are present and that they have the correct syntax. An audit also verifies that there were no errors during deployment by examining the commands configured by the service request on the target devices. If the device configuration does not match what is defined in the service request, the audit flags a warning.

If you do not want the configuration audit to occur, change the value for the Audit parameter. The Audit parameter supports these values:

• Audit—This is the default. A successfully deployed service request is automatically audited unless this flag is changed.
• NoAudit—Do not perform a configuration audit when the service request is deployed.
• ForceAudit—Perform a configuration audit even if the service request deployment is not successful.

You can use the Audit parameter with a Create, Modify, or Decommission service request or a Deployment task. See the “Service Decommission” section for more information. To perform a configuration audit as a separate task, see the “Configuration Audit” section.

Functional Audit

In an MPLS-TP Functional Audit, information is retrieved from source and destination endpoints to

provide tunnel audit information. A functional audit is then performed on service requests, which are not in one of the following states: Draft, Closed, Requested, Invalid, Failed Deploy.

The following is an example of how to create an MPLS-TP Functional Audit via the NBI.

The relevant attributes that need to be set for this service order is RequestName, Type, SubType, and LocatorId, which are highlighted with bold in the example below. In the example, they are set to MplsTpFuncAudit-TASK, task, SubType, and 13.

Example: CreateTaskServiceOrderMplsTpFuncAudit.xml