Network Inventory Overview
Last updated 14 Oct 2026
At a glance
Network inventory is the record of the physical and logical resources that make up the network, and how they connect. It answers two questions that are often held in one platform behind TMF639: what exists and how is it represented, and what is available, reserved or in use. Fulfilment, assurance and planning all depend on it being right.
The picture
One inventory platform, often
TMF639 Resource InventoryQuestion 1 · network inventory
What exists, and how is it represented?
Physical
- Sites
- Racks
- Devices
- Cards
- Ports
- Cables
Logical
- VLANs
- IP addresses
- VRFs
- Slices
Topology
- Containmentrack › device › card › port
- Connectivityport ↔ cable ↔ port
- DependencyVLAN on port, slice on resources
Question 2 · resource inventory
What is available, reserved or in use?
- Plannedordered or designed, not usable yet
- Availableinstalled or created, free to assign
- Reservedheld for one in-flight order
- In useconfigured and serving a service
- Retiredremoved, or released back to the pool
A cancelled order releases Reserved back to Available.
Who reads it, through TMF639
ROM
finds and reserves free resources
Activation
configures them, then marks them in use
Assurance
walks topology from a fault to affected services
Capacity planning
watches utilisation before pools run out
Two questions, not necessarily two systems. Where an estate draws the product boundary varies by vendor.
How it works
What “inventory” means here
In this module, inventory means network resources: devices, ports, cables, VLANs, IP addresses, spectrum, slices and the topology that joins them. What customers have bought (product inventory, TMF637) and the running CFS and RFS instances (service inventory, TMF638) are outputs of order management and are covered in 8.
Two questions, often one platform
People say “network inventory” and “resource inventory” as if they were different systems. They are better read as two questions. What exists and how is it represented? is this section. What is available, reserved or in use? is 10.2. Many estates answer both in the same inventory platform, behind the same TMF639 API; others split them across products. Where the boundary falls varies by vendor and estate.
Physical and logical resources
| Aspect | Physical | Logical |
|---|---|---|
| Examples | Sites, racks, routers, OLTs, cards, ports, cables | VLANs, IP addresses, VRFs, QoS policies, VNF instances, slices |
| Typical lifecycle | Installed → commissioned → in service → decommissioned | Created → assigned → in use → released |
| What runs out | Ports, shelf space, fibre pairs | VLAN IDs, IP pools, slice capacity |
Topology is what makes it useful
Inventory is not a flat list of devices. It models relationships between resources, and those relationships are what fault correlation, capacity planning and activation rely on.
- Containment: a rack holds a chassis, a chassis holds cards, a card holds ports.
- Connectivity: a port on one device connects to a port on another over a fibre link.
- Dependency: a VLAN depends on the ports beneath it; a VNF depends on its compute host.
- Grouping: devices in a point of presence, nodes on an aggregation ring.
When an OLT fails, containment and connectivity tell you which cards, ports and connected customers are affected. Without that model, every fault starts with manual investigation.
Catalog and inventory
The resource catalog (TMF634) defines what types of resource can exist: an OLT model with its port types and capacity. Resource inventory (TMF639) records what actually exists: that OLT, its serial number, its rack. The catalog changes when new equipment types arrive; the inventory changes with every install, swap, allocation and decommission.
Who depends on it
- Fulfilment: ROM looks up free ports, IPs and VLANs. Wrong records cause activation failures or double allocation.
- Assurance: topology turns a failed device into a list of affected services.
- Capacity planning: utilisation of ports, pools and spectrum shows where to build before something runs out.
- Discovery: polling the network shows where the records and reality have drifted apart.
Who owns what
| Entity | System of Record | System of Engagement | System of Reference | Notes |
|---|---|---|---|---|
| Physical resource (site, device, card, port, cable) | Resource inventory | Field operations, logistics | Network planning, capacity planning | Presence, location and hardware state. The network itself is the final word on what is installed. |
| Logical resource (VLAN, IP, VRF, slice) | Resource inventory, or a dedicated IPAM for addresses where one is used | ROM, activation | Service inventory | Where IPAM is separate, which of the two is authoritative for IP addresses must be decided, not assumed. |
| Network topology | Resource inventory | Discovery, SDN controllers | Fault management, capacity planning | Containment, connectivity and dependency relationships. |
| Resource specification | Resource catalog | — | Resource inventory | TMF634. Each inventory record references the specification it is an instance of. |
| Product and service instances | Product inventory / service inventory | — | Resource inventory | TMF637 and TMF638, covered in 8. Resource inventory links to them; it does not own them. |
In practice
Most operators struggle with inventory accuracy. Equipment is swapped without the record being updated, engineers change the network outside the order flow, and migrations leave ghost entries. The gap between what inventory says and what is on the network grows quietly until activation starts failing.
- Stale entries: devices removed from the network but still in inventory.
- Phantom availability: resources marked free that are in use.
- Orphaned logical resources: VLANs with no physical port beneath them.
- Missing topology: devices recorded, connections not.
These compound over time. The usual remedy is continuous reconciliation: discover what is on the network and compare it with the records. Brownfield estates also tend to hold inventory in several places at once (spreadsheets, a planning tool, IPAM, an older inventory product), so the first job is often deciding which one is authoritative for what, before any new platform is introduced.
The trade-off
What it solves
A single, modelled view of what the network contains and how it connects, so fulfilment can assign resources, assurance can find impact, and planning can see exhaustion coming.
What it does not solve
- Accuracy. A model of the network is only as good as the discipline and reconciliation that keep it current.
- Commercial and service truth. What a customer bought and which services run on a resource are held elsewhere.
What it adds
- Topology has to be modelled, not just devices listed, which is significant data work in a brownfield estate.
- Discovery and reconciliation become a permanent operational process, not a migration task.
- Ownership has to be settled where IPAM, planning tools and inventory overlap.
Architecture decision
Answer both inventory questions in one platform, or split them?
One inventory platform
Choose when one product can model physical, logical and topology data and also manage assignment and reservation at the volumes needed
Split across products
Choose when an existing planning or physical inventory tool is staying, or a domain (often IP addressing) already has a capable dedicated system
Breaks if Two products both believe they own the same resource. Assignments made in one are invisible to the other, and double allocation follows.
Takeaways
Key Takeaways
- Inventory in this module means network resources: physical, logical and the topology that joins them.
- Network inventory and resource inventory are two questions, often answered by one platform behind TMF639.
- Topology (containment, connectivity, dependency) is what makes inventory useful for fulfilment, assurance and planning.
- The resource catalog (TMF634) says what can exist; resource inventory (TMF639) records what does.
- Inventory drifts from the network unless it is reconciled continuously.
Check yourself
A colleague says the operator needs to buy a network inventory and a separate resource inventory. How do you respond?Show answerHide
They are two questions, not necessarily two systems: what exists and how it is represented, and what is available, reserved or in use. One platform often answers both behind TMF639. Split them only for a reason, and then settle which one owns each resource.
An OLT fails. What does inventory need to hold for assurance to list the affected customers automatically?Show answerHide
Topology: containment from OLT to cards to ports, connectivity from those ports to the customer premises equipment, and links from resources to the services that use them.