- Preface
- Introduction to the Prime Provisioning API
- Getting Started
- Common APIs
- Using Templates
- Monitoring APIs
- MPLS Provisioning
- L2VPN Provisioning
- VPLS Provisioning
- EVC Provisioning
- Traffic Engineering Management Provisioning
- RAN Backhaul Provisioning
- MPLS Transport Profile Provisioning
- GUI to API Mapping
- Implementing a Notification Server
- Scripts
- Prime Provisioning XDE SDK
- Service Request Examples
- Creating a TDM-CEM (CESoPN) Service Request Without Pseudowire Redundancy
- Creating a TDM-CEM (CESoPN) Service Request With Pseudowire Redundancy
- Creating a RAN Backhaul CEM Class
- Creating a RAN Backhaul TDM Service Request
- Creating a TDM-CEM Service Request for IOS XR
- Creating a TDM-CEM Service Request with E1-E1 Service
- Creating a TDM-CEM Service Request with T1-T1 Service
- Service Request Examples
- Create ATM (VCC) Service Request Without Pseudowire Redundancy
- Create ATM (VCC) Service Request With Pseudowire Redundancy
- Create ATM (PVP) Service Request Without enabling Pseudowire Redundancy:
- Create ATM (PVP) Service Request with Pseudowire Redundancy enabled:
- Create RAN Backhaul ATM Service Request With IOS XR
RAN Backhaul Provisioning
RAN Backhaul APIs in Cisco Prime Provisioning includes provisioning support for creating TDM Circuit Emulation (TDM-CEM) and ATM Pseudowire services. These can be added on top of an existing Prime Provisioning EVC infrastructure.
The TDM-CEM feature supports provisioning of SAToP PW3 and CESoPSN PWE3 services whereas the ATM feature supports provisioning of ATM IMA VCC PWE3 and ATM IMA PVP PWE3 services.
This chapter describes TDM-CEM and ATM Pseudowire service concepts and the steps required to provision services using Prime Provisioning APIs. A provisioning example includes all steps from creating the inventory to auditing the service deployment.
For a detailed description of supported TDM-CEM and ATM Pseudowire features, policy attribute definitions, GUI implementation, and other information, see the Cisco Prime Provisioning 7.2 User Guide.
Policy Types
The following policy types are supported for RAN Backhaul in Prime Provisioning:
- Circuit-Emulation-TDM – Circuit Emulation (TDM) services for RAN backhaul can be defined using this policy type.
- ATM – ATM services for RAN backhaul can be defined using this policy type.
For the list of RAN Backhaul Provisioning Attributes, refer to Table 11-1 :
TDM-CEM Service Definitions
A TDM-CEM service definition specifies the core type, policy subtype, and the attributes common to all EVC attachment circuits. This section lists the supported service definitions, service orders, and policies and includes corresponding examples.
CEM Class Inventory Operations
Prime Provisioning supports the creation of following CEM Class features:
XML file in Cisco Prime Provisioning API 7.2 Programmer Reference: CreateCEMClass.xml
Supported Service Definitions and Service Orders
Prime Provisioning supports the following TDM-CEM features:
– TDM-CEM Service Definition/Policy
– TDM-CEM Service Order/Request
– TDM-CEM Service Definition/Policy
– TDM-CEM Service Order/Request
– TDM-CEM Service Definition/Policy
– TDM-CEM Service Order/Request
Policy Examples
Creating a TDM-CEM (CESoPN) Policy
In this example, a TDM-CEM (CESoPN) policy is created.
XML file in Cisco Prime Provisioning API 7.2 Programmer Reference: CreateTDM_CEM_CESoPN_Policy.xml
The relevant attributes that need to be set for this policy are highlighted in bold in the example. They are RanServiceType, which in the example is set to CESoPN_TIMESLOT, ContainerType, which in the example is set to E1, and UseCemClass, which in the example is set to true.
Creating a TDM-CEM (SAToP) Policy
In this example, a TDM-CEM (SAToP) policy is created.
XML file in Cisco Prime Provisioning API 7.2 Programmer Reference: CreateTDM_CEM_SAToP_Policy.xml
The relevant attributes that need to be set for this policy are highlighted in bold in the example. They are RanServiceType, which in the example is set to SAToP_UNFRAMED, ContainerType, which in the example is set to E1, and UseCemClass, which in the example is set to true.
Creating RAN Backhaul TDM-CEM Policy with IOS XR Support
The following example shows a partial list of properties that can be specified to enable TDM-CEM support for IOS XR devices. These attributes should be added under ServiceDefinitionDetails. These attributes could be used for both the SAToP and the CESoPN type.
If you want to set the AutoPickElineName attribute to false in the request XML, add the following item manually in the service request (instead of the AutoPickElineName tag):
TDM-CEM Service Requests
Before creating a service request, a service policy has to be defined. For information on TDM-CEM policies, see EVC Service Definitions.
A TDM-CEM service request defines the service definition along with the the respective attributes for a EVC-TDM link.
See the Cisco Prime Provisioning 7.2 User Guide for the illustration of RAN Backhaul Services.
Service Request Examples
The following XML examples illustrate how you work with service requests for TDM-CEM APIs. They also demonstrate the kinds of properties (attributes) that need to be specified for each request.
This section includes the following examples:
- Creating a TDM-CEM (CESoPN) Service Request Without Pseudowire Redundancy
- Creating a TDM-CEM (CESoPN) Service Request With Pseudowire Redundancy
- Creating a RAN Backhaul CEM Class
- Creating a RAN Backhaul TDM Service Request
- Creating a TDM-CEM Service Request for IOS XR
- Creating a TDM-CEM Service Request with E1-E1 Service
- Creating a TDM-CEM Service Request with T1-T1 Service
Creating a TDM-CEM (CESoPN) Service Request Without Pseudowire Redundancy
In this example, a TDM-CEM (CESoPN) service request is created without Pseudowire redundancy.
XML file in Cisco Prime Provisioning API 7.2 Programmer Reference: CreateTDM_CEM_CESoPN_SR_PW.xml
The relevant attributes that need to be set for this policy are highlighted in bold in the example. They are CemClassName, which in the example is set to CEM_1, ContainerType, which in the example is set to E1, UseCemClass, which in the example is set to true, Terminal, which in the example is set to A, CemGroupId, which in the example is set to 12, TimeSlot, which in the example is set to 15, ClockSourceType, which in the example is set to INTERNAL, TimeSlot, which in the example is set to 12-16, ClockSourceType, which in the example is set to INTERNAL, AugMappingType, which in the example is set to au-4, Tug3Number, which in the example is set to 1, ChannelModeType, which in the example is set to c-12, Tug2Number, which in the example is set to 2, and E1Number, which in the example is set to 1.
Creating a TDM-CEM (CESoPN) Service Request With Pseudowire Redundancy
In this example, a TDM-CEM (CESoPN) service request is created with Pseudowire redundancy. To enable Pseudowire redundancy, set UseBackPwClass and BackPwClassName while creating the service request.
UseBackPwClass and BackPwClassName are highlighted with bold in this below example.
XML file in Cisco Prime Provisioning API 7.2 Programmer Reference: CreateTDM_CEM_CESoPN_SR_PWRedundancy.xml
The relevant attributes that need to be set for this policy are highlighted in bold in the example. They are Terminal, which in the example is set to A, UseBackPwClass, which in the example is set to true, BackPwClassName, which in the example is set to PW_2.
Creating a RAN Backhaul CEM Class
The following example shows a partial list of properties that can be specified to enable support for IOS XR devices. These attributes should be added under CemClass.
Provide a DummyMode attribute as either USER DEFINED or LAST FRAME as a value. If DummyMode is set as UserDefined, then a hexadecimal value has to be provided by the user for the DummyPattern attribute. Attributes are highlighted in bold below.
Note When the DummyMode attribute is set as LAST FRAME, then there is no need to se the DummyPattern.
Creating a RAN Backhaul TDM Service Request
The following XML example shows a partial list of the properties that can be specified for the attachment circuit EvcLink.
Below highlighted attributes are added to support IOS XR platform and all other attributes would be similar to what is supported for IOS.
Creating a TDM-CEM Service Request for IOS XR
The following XML example shows a partial list of the properties that can be specified for the attachment circuit EvcLink.
The attributes highlighted below are added to support the IOS XR platform. All other attributes are similar to what is supported for IOS.
The relationships between the attributes AugMapptingType and ChannelModeType for both IOS and IOS XR device platforms is shown in Table 11-2.
|
|
|
---|---|---|
Example: CreateIPRAN_TDM_SR_IOS_XR.xml
Creating a TDM-CEM Service Request with E1-E1 Service
The following example sets up an E1-E1 service. To do so, set the attributes of the EvcLink and EvcTDMLinkAttrs classes highlighted below.
Example: Create_TDM_CES_E1-E1_SR.xml
Creating a TDM-CEM Service Request with T1-T1 Service
The following example sets up a T1-T1 service. To do so, set the attributes of the EvcLink and EvcTDMLinkAttrs classes highlighted below.
Example: Create_TDM_SAT_T1-T1_SR.xml
TDM-CEM End-to-End Provisioning Process
This section describes the process for using the API to provision TDM-CEM and includes the required operation, object definition (className), and parameter definitions.
Process Summary
This TDM-CEM provisioning example uses the following processes:
1. Create device groups (optional).
3. Collect device configurations.
Detailed Process
This section describes the process for provisioning TDM-CEM using XML examples.
The complete list of XML examples for ATM Pseudowire 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 device groups (optional).
|
|
|
---|---|---|
Tip If you plan to create device groups, create the empty device groups before you create the devices. As you create each device, add the associated device group name as a key property in the create device XML request.
In the following example, the device group (CustDev) is added as a key property when creating the device CiscoRouter:
Every network element that Prime Provisioning manages must be defined as a device in the system. An element is any device from which Prime Provisioning can collect configuration information.
|
|
|
---|---|---|
Step 3 Collect device configurations.
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 NBI API.
|
|
|
---|---|---|
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.
|
|
|
---|---|---|
Each provider can contain multiple regions.
|
|
|
---|---|---|
Step 6 Declare devices as PEs.
The XML request that assigns a PE role to a device is also used to:
|
|
|
---|---|---|
A customer is a requestor of VPN services. Each customer can contain multiple customer sites. Each site belongs to only one customer and can contain multiple CPEs.
|
|
|
---|---|---|
For a VPLS VPN, all PE-POP routers use the same VC ID to establish the virtual circuit (VC) across the provider core. The VC ID is also the VPN ID and is assigned from the VC ID pool. Prime Provisioning ensures that VC IDs are unique among VPLS VPNs.
Note A VC ID pool is global (not associated with a provider or organization).
|
|
|
---|---|---|
Step 9 Create TDM-CEM service definition (policy).
A TDM-CEM service definition specifies the service subtype, device properties, and the attributes common to all attachment circuits.
Step 10 Create TDM-CEM service request.
A TDM-CEM service request defines 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.
- CreateTDM_CEM_CESoPN_SR_PW.xml
- CreateTDM_CEM_CESoPN_SR_PWRedundancy.xml (use this example if there is PW Redundancy to be created)
- CreateTDM_CEM_SAToP_SR_PW.xml
- CreateTDM_CEM_SAToP_SR_PWRedundancy.xml(use this example if there is PW Redundancy to be created)
- CreateIPRAN_TDM_SR_IOS_XR.xml
Auditing Service Requests
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 and sets the service request to a Failed Audit or Lost state.
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.
ATM Pseudowire Service Definitions
An ATM Pseudowire service definition specifies the core type, policy subtype, and the attributes common to all EVC attachment circuits. This section lists the supported service definitions, service orders, and policies and includes corresponding examples.
Supported Service Definitions and Service Orders
Prime Provisioning supports the following ATM Pseudowire features:
– ATM Service Definition/Policy
– ATM Service Definition/Policy
– ATM Service Definition/Policy
Policy Examples
The following constitute XML policy examples for ATM Pseudowire:
XML file in Cisco Prime Provisioning API 7.2 Programmer Reference: CreateATM_IMA_Policy.xml
Create ATM Pseudowire Policy
In this example, an ATM Pseudowire policy is created.
Creating RAN Backhaul ATM Policy with IOS XR Support
The following example shows a partial list of properties that can be specified to enable ATM support for IOS XR devices. These attributes should be added under ServiceDefinitionDetails.
ATM Pseudowire Service Requests
Before creating a service request, a service policy has to be defined. For information on ATM Pseudowire policies, see EVC Service Definitions.
An ATM Pseudowire service request defines the service definition along with the the respective attributes for a EVC-TDM link.
See the Cisco Prime Provisioning 7.2 User Guide for the illustration of RAN Backhaul Services.
Service Request Examples
The following XML examples illustrate how you work with service requests for ATM Pseudowire APIs. They also demonstrate the kinds of properties (attributes) that need to be specified for each request.
This section includes the following examples:
- Create ATM (VCC) Service Request Without Pseudowire Redundancy
- Create ATM (VCC) Service Request With Pseudowire Redundancy
- Create ATM (PVP) Service Request Without enabling Pseudowire Redundancy:
- Create ATM (PVP) Service Request with Pseudowire Redundancy enabled:
- Create RAN Backhaul ATM Service Request With IOS XR
Create ATM (VCC) Service Request Without Pseudowire Redundancy
In this example, a ATM Pseudowire (VCC) service request is created without Pseudowire redundancy.
XML file in Cisco Prime Provisioning API 7.2 Programmer Reference: CreateATM_IMA_VCC_SR_PW.xml
The relevant attributes that need to be set for this policy are highlighted in bold in the example. They are MCPTTimer1, which in the example is set to 1652, MCPTTimer2, which in the example is set to 6245, MCPTTimer3, which in the example is set to 8246, Terminal, which in the example is set to A, MCPTTimerToUse, which in the example is set to 2, and Terminal, which in the example is set to Z.
Create ATM (VCC) Service Request With Pseudowire Redundancy
In this example, a ATM Pseudowire (VCC) service request is created with Pseudowire redundancy. To enable Pseudowire redundancy, set UseBackPwClass and BackPwClassName while creating the service request.
UseBackPwClass and BackPwClassName are highlighted with bold in this below example.
XML file in Cisco Prime Provisioning API 7.2 Programmer Reference: CreateATM_IMA_VCC_SR_PWRedundancy.xml
Create ATM (PVP) Service Request Without enabling Pseudowire Redundancy:
In this example, a ATM Pseudowire (PVP) service request is created without Pseudowire redundancy.
XML file in Cisco Prime Provisioning API 7.2 Programmer Reference: CreateATM_IMA_PVP_SR_PW.xml
The relevant attributes that need to be set for this policy are highlighted in bold in the example. They are MCPTTimer1, which in the example is set to 1505, MCPTTimer2, which in the example is set to 3205, MCPTTimer3, which in the example is set to 5505, Terminal, which in the example is set to A, MCPTTimerToUse, which in the example is set to 3, and Terminal, which in the example is set to Z.
Create ATM (PVP) Service Request with Pseudowire Redundancy enabled:
In this example, a ATM Pseudowire (PVP) service request is created with Pseudowire redundancy. To enable Pseudowire redundancy, set UseBackPwClass and BackPwClassName while creating the service request.
UseBackPwClass and BackPwClassName are highlighted with bold in this below example.
XML file in Cisco Prime Provisioning API 7.2 Programmer Reference: CreateATM_IMA_PVP_SR_PWRedundancy.xml
Create RAN Backhaul ATM Service Request With IOS XR
The following example shows a partial list of properties that needs to be specified to enable support for IOS XR devices. These attributes should be added under EvcLink (L2VpnGrpName and AutoPickElineName).
ATM Pseudowire End-to-End Provisioning Process
This section describes the process for using the API to provision ATM Pseudowire and includes the required operation, object definition (className), and parameter definitions.
Process Summary
This ATM Pseudowire provisioning example uses the following processes:
1. Create device groups (optional).
3. Collect device configurations.
Detailed Process
This section describes the process for provisioning ATM Pseudowire using XML examples.
The complete list of XML examples for ATM Pseudowire 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 device groups (optional).
|
|
|
---|---|---|
Tip If you plan to create device groups, create the empty device groups before you create the devices. As you create each device, add the associated device group name as a key property in the create device XML request.
In the following example, the device group (CustDev) is added as a key property when creating the device CiscoRouter:
Every network element that Prime Provisioning manages must be defined as a device in the system. An element is any device from which Prime Provisioning can collect configuration information.
|
|
|
---|---|---|
Step 3 Collect device configurations.
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 NBI API.
|
|
|
---|---|---|
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.
|
|
|
---|---|---|
Each provider can contain multiple regions.
|
|
|
---|---|---|
Step 6 Declare devices as PEs.
The XML request that assigns a PE role to a device is also used to:
|
|
|
---|---|---|
A customer is a requestor of VPN services. Each customer can contain multiple customer sites. Each site belongs to only one customer and can contain multiple CPEs.
|
|
|
---|---|---|
For a VPLS VPN, all PE-POP routers use the same VC ID to establish the virtual circuit (VC) across the provider core. The VC ID is also the VPN ID and is assigned from the VC ID pool. Prime Provisioning ensures that VC IDs are unique among VPLS VPNs.
Note A VC ID pool is global (not associated with a provider or organization).
|
|
|
---|---|---|
Step 9 Create ATM Pseudowire service definition (policy).
A ATM Pseudowire service definition specifies the service subtype, device properties, and the attributes common to all attachment circuits.
|
|
|
---|---|---|
Note If you do not specify a Provider or Organization, the service policy is global |
||
Step 10 Create ATM Pseudowire service request.
A ATM Pseudowire service request defines 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.
- CreateATM_IMA_PVP_SR_PW.xml
- CreateATM_IMA_PVP_SR_PWRedundancy.xml (only if PW redundancy needs to be created for ATM IMA PVP Service)
- CreateATM_IMA_VCC_SR_PW.xml
- CreateATM_IMA_VCC_SR_PWRedundancy.xml (only if PW redundancy needs to be created for ATM IMA VCC Service)
- CreateIPRAN_ATM_SR_IOS_XR.xml
Auditing Service Requests
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 and sets the service request to a Failed Audit or Lost state.
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.