Resource Manager API Guide (4.2.12)
Description of the APIs exposed by the Resource Manager package.
About this Guide
This NSO Resource Manager (RM) API Guide describes the APIs exposed by the Resource Manager package that you can use to allocate IPs from the IP resource pool and to allocate the IDs from ID resource pools.
Intended Audience
This guide is intended for Cisco advanced services developers, network engineers, and system engineers to install the RM package inside NSO and then utilize the APIs exposed by the RM package to allocate and manage IP subnets and IDs as required by other CFPs installed alongside this RM package inside NSO.
Additional Documentation
This documentation requires the reader to have a good understanding of NSO and its usage as described in the following NSO documentation:
Resource Manager IP/ID Allocation APIs
The APIs exposed by the Resource Manager package are used to allocate IP subnets and IDs from the IP and ID resource pools respectively by the applications requesting the resources. The APIs help to allocate, update, or deallocate the resources. You can make API calls to the resource pools as long as the pool is not exhausted of the resources. If the pool is exhausted of resources or if the referenced pool does not exist in the database when there is a request, the allocation raises an exception. The APIs also support allocating Odd or Even IDs from the resource pools, provided the pool has available resources.
When a service makes multiple resource allocations from a single pool, the optional ‘name’ parameter allows the service to distinguish the different allocations. By default, the parameter value is an empty string.
Resource allocation can be synchronous or asynchronous.

The synchronized allocation API request uses Reactive FastMap to allocate resources while ensuring the interface appears synchronous. This means that as you create an allocation request from northbound, you can see the allocation results, such as the requested IP subnet or ID in the same transaction. If a northbound is making an allocation request and, in the same transaction, a configuration is being applied to a specific device, the commit dry-run receives the request response which is processed by the Resource Manager. The configurations are then pushed to the device in the same transaction. Thus, the northbound user can see the get-modifications in the commit dry-run.
During a resource request, the resource is allocated and stored in the create callback. This allocation is visible to other services that are run in the same or subsequent transactions and therefore avoids the recreation of resource when the service is redeployed. Synchronous allocation does not require service re-deploy to read allocation. The same transaction can read allocation. Commit dry-run or get-modification displays the allocation details as output.
Example
The following is an example for a Northbound service callback passed with required API parameters for both synchronous and asynchronous IPv4 allocations. The example uses pool-example package as a reference. The request describes the details it uses, such as the pool, device. Each allocation has an allocation ID. In the following example, the allocating service pulls one IPv4 address from the IPv4 resource pool. The requesting service then uses this allocated IP address to set the interface address on the device southbound to NSO.
The payloads below demonstrate the Northbound service allocation request using the Resource Manager synchronous and asynchronous flows. The API pulls one IP address from the IPv4 resource pool and sets the returned IP address on the interface IOS1 device. The payloads demonstrate both synchronous and asynchronous flows.
IPv4 and IPv6 have separate IP pool types; there is no mixed IP pool. You can specify a prefixlen parameter for IP pools to allocate a net of a given size. The default value is the maximum prefix length of 32 and 128 for IPv4 and IPv6, respectively.
The following APIs are used in IPv4 and IPv6 allocations.
IP Allocations
Resource Manager exposes the API calls to request IPv4 and IPv6 subnet allocations from the resource pool. These requests can be synchronous or asynchronous. This topic discusses the APIs for these flows.
The NSO Resource Manager interface and the resource allocator provide a generic resource allocation mechanism that works well with services. Each pool has an allocation list where services are expected to create instances to signal that they request an allocation. The request parameters are stored in the request container, and the allocation response is written in the response container.
The APIs exposed by RM are implemented in Python as well as Java, so the NB user can configure the service to be a Java package or a Python package and call the allocator API as per the implementation. The NB user can also use NSO CLI to make an allocation request to the IP allocator RM package.
The IP resource pool supports two types of allocation methods, namely firstfree and sequential. You can specify the allocation method by setting the parameter allocation-method for an IP pool. The default allocation method is firstfree (legacy allocation method), where a released IP subnet can be reused immediately, while in the sequential allocation method, the released subnets are stored separately in a available-secondary set. When an allocation request is made and the requested subnet is not present in the available set, the subnets can be allocated from the available-secondary set.
By default, the available-secondary set is hidden and user must run the command unhide debug to view the details of the available-secondary set of an IP pool.
Using Java APIs for IP Allocations
This section covers the Java APIs exposed by the RM package to the NB user to make IP subnet allocation requests.
Creating Asynchronous IP Subnet Allocation Requests
The asynchronous subnet allocation requests can be created for a requesting service with:
The redeploy type set to
defaulttype or set toredeployType.The CIDR mask length can be set to invert the subnet mask length for Boolean
operations with IP addresses or set not to be able to invert the subnet mask length.
Pass the starting IP address of the subnet to the requesting service redeploy type
(
default/redeployType).
The following are the Java APIs for asynchronous IP allocation requests.
Creating Synchronous or Asynchronous IP Subnet Allocation Requests
The sync_alloc parameter in the API determines if the allocation request is for a synchronous or asynchronous mode. Set the sync_alloc parameter to true for synchronous flow.
The subnet allocation requests can be created for a requesting service with:
The redeploy type set to default type or
redeployTypetype.The CIDR mask length can be set to invert the subnet mask length for Boolean operations with IP addresses or set to not be able to invert the subnet mask length.
Pass the starting IP address of the subnet to the requesting service redeploy type (
default/redeploytype).
The following are the Java APIs for synchronous or asynchronous IP allocation requests.
Verifying Responses for IP Allocations – Java APIs
Once the requesting service requests allocation through an API call, you can verify if the corresponding response is ready. The responses return the properties based on the request.
The following APIs help you to check if the response for the allocation request is ready.
Reading IP Allocation Responses for Java APIs
The following API reads the allocated IP subnet from the resource pool once the allocation request response is ready.
Using Java APIs for Non-service IP Allocations
This non-service IP address allocation API is created from Resource Manager 4.2.12.
Using Python APIs for IP Allocations
Creating Python APIs for IP Allocations
The RM package exposes Python APIs to manage allocation for IP subnet from the resource pool.
Below is the list of Python APIs exposed by the RM package.
Using Python APIs for Non-Service IP Allocations
Creating Python APIs for IP Allocations
The RM package exposes Python APIs to manage non-service allocation for IP subnet from the resource pool. Below is the list of Python APIs exposed by the RM package.
ID Allocations
RM package exposes APIs to manage ID allocation from the ID resource pool. The APIs are available to request ID, check if the allocation is ready and also to read the allocation once ready.
Using JAVA APIs for ID Allocations – Asynchronous Old APIs
The following are the asynchronous old Java APIs for ID allocation from the RM resource pool.
Using JAVA APIs for Non-Service ID Allocations
The following API is used to create or update an ID allocation request with non-service.
Verifying Responses for ID Allocations – Java APIs
RM package exposes responseReady Java API to verify if the ID allocation request is ready or not.
The following APIs are used to verify if the response is ready for an ID allocation request.
Reading ID Allocation Responses for Java APIs
The following API reads information about specific allocation requests made by the API call. The response returns the allocated ID from the ID pool.
Using JAVA APIs for ID Allocations – Synchronous/Asynchronous New APIs
The following are the synchronous/asynchronous new Java APIs exposed by the RM package for ID allocation from the resource pool.
Using Python APIs for ID Allocations
The RM package also exposed Python APIs to request ID allocation from a resource pool. The below APIs are Python APIs exposed by RM for ID allocation.
Using Python APIs for Non-Service ID Allocation
The RM package also exposes Python APIs to request ID allocation from a resource pool by passing the maapi object and transaction handle instead of the service. The below APIs are Python APIs for non-service ID allocation.
Use the module resource_manager.id_allocator.
Troubleshoot & Debug
Set the Java Debug
Check the Log File
RM processing logs are in the file ncs-java-vm.log. Here is the example RM API entry point msg called from the services:
Use the RM Action Tool
Last updated
Was this helpful?

