Resource Inventory
Resource Inventory: The Infrastructure Runtime View
Resource Inventory is the deepest layer of the inventory stack. It tracks every physical and logical resource in the operator's network: devices, ports, cables, IP addresses, VLANs, spectrum allocations, virtual network functions, and more. This is where the abstract concepts of CFS and RFS connect to the concrete reality of network hardware and configuration.
Resource Inventory serves two audiences: service fulfilment (which resources are available to allocate?) and network operations (what is deployed, where, and in what state?). It is the bridge between the service domain and the physical/logical network.
Physical vs Logical Resources
Resources in telecom fall into two fundamental categories: physical (tangible hardware you can touch) and logical (software-defined configurations that exist in device memory or management systems). Both types are tracked in Resource Inventory, but they have different management concerns.
Physical vs Logical Resources
| Aspect | Physical Resources | Logical Resources |
|---|---|---|
| Definition | Tangible hardware components | Software-defined configurations and allocations |
| Examples | OLT, ONT, router, switch, antenna, fibre cable, SFP module | VLAN ID, IP address, QoS policy, DHCP scope, VPN instance |
| Lifecycle concern | Procurement, installation, maintenance, decommission | Allocation, configuration, release |
| Location tracking | Physical location (site, rack, shelf, slot) | Logical location (device, interface, namespace) |
| Capacity | Fixed by hardware (ports, slots, bandwidth) | Pool-based (address ranges, VLAN ranges, policy limits) |
| Failure mode | Hardware failure, wear, environmental damage | Misconfiguration, exhaustion, conflict |
| Field operations | Requires truck roll for install/replace | Configured remotely via management interfaces |
Compound and Virtual Resources
Modern networks increasingly rely on compound resources — resources that are themselves composed of other resources. Virtual Network Functions (VNFs), network slices, and software-defined network constructs are examples. These blur the physical/logical boundary and require more sophisticated inventory modeling.
- VNF (Virtual Network Function): A software instance running on virtualised infrastructure. Examples: virtual router, virtual firewall, virtual session border controller
- Network Slice: A logically isolated network partition with dedicated resources and SLA. Composed of multiple physical and logical resources across the network
- SD-WAN Overlay: A software-defined WAN construct that abstracts underlying transport resources
- Container/Pod: In cloud-native deployments, Kubernetes pods running network functions, tracked as resource instances
Network Topology in Resource Inventory
Resource Inventory does not just track individual resources — it also captures how resources are connected to form the network topology. This topology information is essential for path computation, impact analysis, and capacity planning.
Containment relationships model the physical hierarchy: a site contains racks, racks contain shelves, shelves contain cards, cards contain ports. This hierarchy is essential for understanding the physical structure of the network and for field operations.
- Site → Building → Floor → Room → Rack → Shelf → Card → Port
- Used for: Physical location tracking, field dispatch, capacity planning
- Example: OLT-EAST-07 is in Rack A3, Shelf 2, at Exchange EAST-CENTRAL
Resource Allocation and Pool Management
During service fulfilment, specific resources must be allocated from available pools and assigned to the new service instance. This allocation process is one of the most operationally critical functions of Resource Inventory.
Resource Allocation During Fulfilment
Resource Requirement Identified
SOM / Service CatalogThe RFS decomposition identifies that the service needs: 1 OLT port, 1 VLAN ID, 1 IP address, and 1 QoS profile.
Availability Check
Resource InventoryResource Inventory is queried for available resources at the serving location. Are there free ports on the OLT? Are there VLAN IDs and IP addresses available in the correct pools?
Resource Selection
Resource Allocation EngineSpecific resources are selected based on allocation policies (e.g., next available port, nearest IP address, specific VLAN range for the service type).
Reservation
Resource InventorySelected resources are marked as "Reserved" in Resource Inventory to prevent double-allocation. Other orders cannot use these resources while reserved.
Activation and Confirmation
Resource Inventory / ActivationOnce the activation engine successfully configures the resources on the network, Resource Inventory updates their state to "Allocated/In-Use" and records the service instance reference.
Resource Lifecycle States
Resources follow a lifecycle from initial installation through to decommissioning. The lifecycle states differ somewhat between physical and logical resources.
Resource Lifecycle States
| State | Physical Resource | Logical Resource |
|---|---|---|
| Planned | Ordered from vendor, not yet installed | Defined but not yet provisioned on any device |
| Installed / Available | Physically installed, tested, and ready for use | Created in pool, available for allocation |
| Reserved | Earmarked for a specific order but not yet configured | Allocated to an order but not yet activated |
| In Use / Operating | Actively carrying traffic or serving a customer | Configured on a device and assigned to a service |
| Suspended | N/A (physical resources remain in place) | Configuration disabled but not removed |
| Standby | Part of a protection scheme, ready to take over | Backup configuration ready to activate on failover |
| Under Maintenance | Taken out of service for maintenance or repair | N/A |
| Decommissioned | Physically removed or marked for disposal | Deleted from device, returned to pool or retired |
IP Address and VLAN Management
Two of the most common logical resource types are IP addresses and VLAN IDs. Both are finite pools that must be carefully managed to avoid exhaustion, conflicts, and allocation errors.
IPAM tracks IP address pools, subnet allocations, and individual address assignments. It ensures that every allocated IP is unique within its scope and that pools are not exhausted without warning.
- IP pools are defined per region, service type, or access technology
- Subnets are carved from pools and assigned to network segments
- Individual IPs are allocated from subnets during fulfilment
- IPAM tracks: allocated, available, reserved, quarantined (recently released) states
- IPv4 exhaustion makes efficient IPAM increasingly critical
- IPAM may be a module within Resource Inventory or a specialized system
Capacity Planning with Resource Inventory
Resource Inventory is the primary data source for capacity planning. By analyzing current utilization and allocation trends, network planning teams can predict when resources will be exhausted and proactively expand capacity.
Resource Utilization Metrics
Key utilization metrics include: port utilization (% of OLT ports in use), address pool depletion rate, VLAN availability per access ring, bandwidth utilization per aggregation link, and spectrum allocation for wireless resources.
Capacity Planning by Resource Type
| Resource | Capacity Metric | Expansion Lead Time | Planning Horizon |
|---|---|---|---|
| OLT Ports | Ports in use vs total ports | Weeks (new cards) to months (new OLT) | 6-12 months |
| IP Addresses | Addresses allocated vs pool size | Days (new ranges) to weeks (new subnets) | 3-6 months |
| VLAN IDs | VLANs in use per ring | Days (new ranges) to weeks (VLAN re-engineering) | 3-6 months |
| Aggregation BW | Traffic vs link capacity | Weeks (new links) to months (new nodes) | 6-18 months |
| Spectrum (wireless) | Allocated MHz vs available | Months (re-farming) to years (new spectrum) | 12-36 months |
TMF639 Resource Inventory Management API
TMF639 Key Operations
| Operation | Method | Purpose | Example |
|---|---|---|---|
| List Resources | GET /resource | Retrieve resource instances with filtering | GET /resource?resourceSpecification.id=RS-OLT-PORT&state=available&place.id=SITE-EAST |
| Get Resource | GET /resource/{id} | Retrieve a specific resource with full details | GET /resource/RES-OLT-E07-P03 |
| Create Resource | POST /resource | Register a new resource instance (after physical install or logical creation) | POST with resource spec ref, characteristics, place, relationships |
| Update Resource | PATCH /resource/{id} | Modify attributes or state (e.g., mark as allocated) | PATCH with state=operating, serviceRef=SI-RFS-GPON-88421 |
| Delete Resource | DELETE /resource/{id} | Remove a resource instance (physical decommission or logical cleanup) | DELETE /resource/RES-OLT-E07-P03 |
Resource Discovery and Reconciliation
Resource Inventory is only useful if it reflects reality. Resource discovery is the process of scanning the network to detect what resources actually exist, and reconciliation compares discovered state against inventory records to identify discrepancies.
Imagine a library where the catalog says "shelf 3, row 2" but the book has been moved. In networking, equipment gets replaced, ports get recabled, and configurations change — sometimes without updating inventory. Discovery is like walking through the library and checking every shelf against the catalog.
- SNMP polling: Query devices for interface status, serial numbers, firmware versions
- NETCONF/YANG: Retrieve structured configuration and operational data
- CLI scraping: Parse command outputs from network devices (legacy approach)
- SDN controller APIs: Query centralized controllers for topology and resource state
- OSS/NMS mediation: Use existing network management systems as discovery proxies
Reconciliation typically runs as a scheduled batch process or triggered event. The reconciliation engine compares discovered resources against inventory and classifies discrepancies into: (1) Missing in inventory — resource exists on network but not in inventory (add it); (2) Missing on network — inventory entry exists but resource not found (flag for investigation); (3) Attribute mismatch — resource exists in both but attributes differ (determine which is correct); (4) State mismatch — resource state differs between inventory and network (typically network wins).
The key design decision is which source wins when there is a discrepancy. For physical presence, the network always wins (if a device is not responding, it is gone). For configuration state, it depends on the operator's design intent model — sometimes inventory represents the intended state and the network should be corrected.
Resource Inventory Source of Record
Resource Inventory SoR Mapping
| Entity | System of Record | System of Engagement | System of Reference | Notes |
|---|---|---|---|---|
| Physical Resource Instance | Resource Inventory / Network Inventory | Field Operations, Logistics | Service Inventory, Network Planning | Authoritative for physical device presence, location, and hardware state. |
| Logical Resource Instance | Resource Inventory | ROM / Activation Engine | Service Inventory, IPAM | Authoritative for logical resource allocation (VLAN, IP, QoS). |
| Resource State | Resource Inventory (reconciled with network) | Activation / NMS | Service Inventory, Capacity Planning | State must be reconciled with actual network state. |
| Network Topology | Resource Inventory / Network Inventory | Network Planning, Field Ops (connectivity changes) | Service Assurance, Path Computation | Containment, connectivity, and dependency relationships. |
| Resource Capacity / Utilization | Resource Inventory + Performance Management | Network Planning (threshold management) | Capacity Planning, Business Intelligence | Combines inventory counts with performance data. |
Section 4.4 Key Takeaways
- Resource Inventory tracks every physical and logical resource: devices, ports, cables, VLANs, IPs, VNFs, and more
- Physical resources are tangible hardware; logical resources are software-defined allocations; compound resources aggregate both
- Network topology (containment, connectivity, dependency, grouping) is a core part of Resource Inventory
- Resource allocation during fulfilment requires availability checks, selection, reservation, and confirmation to prevent double-allocation
- Resource lifecycle states span from Planned through Installed, Reserved, In-Use, to Decommissioned
- IPAM and VLAN management are critical sub-functions of Resource Inventory for address and identifier pool management
- TMF639 provides standardized CRUD and event notification for resource instances
- Resource discovery and reconciliation are essential to maintain accuracy between inventory records and actual network state