Resource Inventory
Last updated 14 Oct 2026
At a glance
Resource inventory records every physical and logical resource instance, its lifecycle state, and which service it is assigned to. During fulfilment it answers the question “what is available, reserved or in use?”, so that resources are assigned once and only once. It is often the same platform as network inventory, exposed through TMF639.
The picture
Service Order Management (SOM)
Decomposes commercial order into CFS → RFS
Service Order
Broadband 200Mbps
Service Inventory (TMF638)
CFS and RFS instances created — service is ‘Designed’
CFS: Internet Access
200Mbps — state: Designed
GPON Bearer
RFS
VLAN Svc
RFS
IP Profile
RFS
QoS Profile
RFS
Resource Inventory (TMF639)
Resources checked, selected, and reserved — service moves to ‘Reserved’
OLT Port
Reserved
VLAN ID
Reserved
IP Address
Reserved
QoS Policy
Reserved
Activation Engine
Generates vendor-specific config from templates, pushes to network
Activation Engine
Template rendering → config push
Network Elements
Physical and logical resources configured — service becomes ‘Active’
OLT
Switch
BNG
RADIUS
How it works
What a resource instance holds
Each instance references a resource specification from the resource catalog (TMF634) and adds what is specific to it: serial number, location, firmware, an assigned IP address, its lifecycle state, and the service instance it serves. TM Forum SID classes resources as physical (equipment), logical (configuration such as a VLAN or IP address) and compound (resources built from others, such as a slice or an SD-WAN overlay). TMF639 handles all three.
Assignment during fulfilment
Requirement
SOM / catalogDecomposition of the RFS says what is needed: one access port, one VLAN, one IP address, one QoS profile.
Check and select
TMF639Inventory is searched for free resources at the serving location, and specific ones are chosen by allocation policy (next free port, a VLAN range, the right IP pool).
Reserve
TMF639The chosen resources are marked Reserved so no other in-flight order can take them.
Confirm
TMF639Once activation succeeds, the state moves to In use and the service instance is recorded against each resource.
Who drives steps 2 and 3 varies. Where a ROM is used, it usually calls inventory to assign and reserve; where it is not, the SOM workflow or a domain controller does. The inventory records the outcome either way.
Lifecycle states
| State | Physical resource | Logical resource |
|---|---|---|
| Planned | Ordered from the vendor, not installed | Defined, not yet created |
| Available | Installed, tested, ready | In a pool, free to assign |
| Reserved | Held for a specific order | Assigned to an order, not yet configured |
| In use | Carrying traffic | Configured on a device for a service |
| Retired | Removed or awaiting disposal | Deleted from the device, returned to the pool |
Double allocation
The commonest failure is two orders taking the same resource at once. The usual defences are locking during selection, optimistic checks that re-read state before committing and retry on conflict, and reservation timeouts that release a resource if activation is not confirmed within a window.
IP addresses and VLANs
- IP addressing (IPAM): pools and subnets per region, service or access technology. IPv4 scarcity makes efficient allocation matter.
- VLANs: IDs 1 to 4094, usually partitioned by service type, with scope rules for where an ID must be unique. Running out on one access ring blocks new activations there.
Discovery and reconciliation
Discovery reads what is actually on the network (SNMP, NETCONF/YANG, controller APIs, CLI on older equipment). Reconciliation compares it with the records. A resource missing from inventory is added; one missing from the network is investigated; attribute and state mismatches need a rule for which side wins, and for physical presence it is normally the network.
Who owns what
| Entity | System of Record | System of Engagement | System of Reference | Notes |
|---|---|---|---|---|
| Physical resource instance | Resource inventory | Field operations, logistics | Network planning, service inventory | Presence, location, hardware state. Often the same platform as network inventory. |
| Logical resource instance (VLAN, QoS profile) | Resource inventory | ROM, activation | Service inventory | TMF639. |
| IP address assignment | Resource inventory or a dedicated IPAM, depending on the estate | ROM, activation | Resource inventory | Where both exist, one must be named authoritative and the other kept in step with it. |
| Reservation | Resource inventory | ROM or the SOM workflow | — | Held for the life of the order; released on cancellation, rollback or timeout. |
| Resource specification | Resource catalog | — | Resource inventory | TMF634. Inventory instances reference it. |
| Actual device state | The network element | — | Resource inventory, via discovery | Inventory is a model of the network; reconciliation keeps the two close. |
In practice
Assignment logic is where the inventory platform earns its place or does not. Simple “next free port” rules work for one access technology; real estates need proximity, capacity headroom, VLAN scope and IP pool rules, and those rules accumulate in the inventory product, in ROM, or in workflow scripts. Wherever they live, they need an owner.
IP addressing is often held in a dedicated IPAM tool that predates the inventory programme. Bringing IP assignment into resource inventory is not always worth it; leaving it out means two systems that must agree on every assignment.
In brownfield estates, many in-use resources were configured before the current inventory existed and carry no link to a service instance. Discovery can find the resources; it cannot tell you which customer they belong to. That linkage is usually rebuilt from billing and service records, with gaps that have to be worked through by hand.
The trade-off
What it solves
Resources are assigned once, tracked through their lifecycle and tied to the service that uses them, so fulfilment does not collide and operations can see what serves whom.
What it does not solve
- Accuracy on its own. Records drift from the network without discovery and reconciliation.
- Historical lineage. Resources configured before the inventory existed rarely link cleanly to a service or customer.
What it adds
- Reservation needs locking, retry and timeout handling, tested under concurrent order load.
- Allocation policies become business rules that need ownership and change control.
- A reconciliation policy is needed: when records and network disagree, which wins, and who decides.
Architecture decision
When records and the network disagree, correct inventory automatically or flag and hold?
Auto-correct inventory from discovery
Choose when discovery is reliable for the domain and the attribute is physical presence or running state
Flag for review
Choose when the mismatch touches design intent or service assignment, where the network may be the one that is wrong
Breaks if Everything is flagged and nobody works the queue, or everything is auto-corrected and unauthorised network changes are silently written into the record as truth.
Takeaways
Key Takeaways
- Resource inventory records each resource instance, its lifecycle state and the service it serves.
- Assignment is check, select, reserve, confirm; reservation is what prevents double allocation.
- Lifecycle states run from Planned through Available, Reserved and In use to Retired.
- IP and VLAN pools are finite and can block activation when they run out.
- Discovery and reconciliation keep the record close to the network; the reconciliation policy is a decision, not a default.
Check yourself
Two orders for neighbouring premises are assigned the same OLT port. Which control failed?Show answerHide
Reservation. The port should have moved to Reserved for the first order before the second selected it, with locking or an optimistic check before commit.
Discovery finds a VLAN configured on a device that inventory shows as free. What do you do?Show answerHide
Treat it as a mismatch to investigate, not just to overwrite. Mark it unavailable so it cannot be assigned, then find out whether it belongs to a service configured outside the order flow, and record the link if so.