CFS, RFS & Resource Explained
Last updated 14 Oct 2026
At a glance
Below the product sit three progressively more technical layers. The Customer-Facing Service (CFS) is the service as the customer experiences it, independent of technology. The Resource-Facing Service (RFS) is how one technology implements it. The Resource is what is actually allocated on the network. Keeping the layers apart lets the network change without the product changing.
The picture
Product Specification
Customer-Facing Service
Resource
Resource
Resource
Resource
How it works
Three layers below the product
The Product Specification says what is sold (3.1). It does not say how the network delivers it. That job belongs to three layers, each more technical than the one above, and each defined as a specification in a catalog before any order arrives.
An RFS is still a service
In the TM Forum SID, CFS and RFS are both kinds of service specification; the RFS is not a resource. The distinction is visibility. A CFS is what a product is realised by, and a customer could recognise it. An RFS is internal: it groups the technical behaviour needed to deliver a CFS on one technology, and it is what binds to resources. Resources split into physical (a port, a card, a fibre) and logical (a VLAN ID, an IP address, a policy).
Why three layers rather than one
Each layer isolates a different kind of change. The CFS shields the product from technology choices: moving a customer from copper to fibre changes the RFS beneath Internet Access, not the CFS, and not the product. The RFS keeps technology-specific logic out of the customer layer. Resources can be planned, reserved and released on their own, which is what capacity management needs. Each layer changes at its own pace.
CFS, RFS and Resource side by side
| CFS | RFS | Resource | |
|---|---|---|---|
| Represents | The service as experienced | A technical service component | A network element or logical value |
| Technology | Neutral | Specific | Specific, and often vendor-specific |
| Example | Internet Access | GPON bearer, IP profile | OLT port, IP address |
| Specification held in | Service catalog | Service catalog | Resource catalog |
| Instance held in | Service inventory | Service inventory | Resource inventory |
| Ordered by | COM, through SOM | SOM | ROM |
One CFS, several implementations
Because the CFS is technology-neutral, one CFS specification can decompose into different RFS combinations. Internet Access becomes a GPON bearer, VLAN and IP profile on fibre, and a DOCSIS service flow and IP profile on cable. The choice is made at order time from facts such as the address or the available access network. The rules are covered in 3.3.
Specification and instance
Everything above describes specifications: catalog entries that define what may exist. At order time each specification is instantiated. Service order management creates CFS and RFS instances in service inventory (TMF638); resource order management allocates resource instances in resource inventory (TMF639). Every instance records the specification it was created from, which is what makes the chain traceable later.
Who owns what
| Entity | System of Record | System of Engagement | System of Reference | Notes |
|---|---|---|---|---|
| CFS Specification | Service Catalog | — | Product Catalog, SOM | TMF633. Referenced by Product Specifications through the realisation relationship. |
| RFS Specification | Service Catalog | — | SOM, ROM | TMF633. Often held in the same service catalog as CFS, sometimes in an OSS-side design tool. |
| Resource Specification | Resource Catalog | — | ROM, Resource Inventory | TMF634. In many estates this sits inside the resource inventory product rather than a separate catalog. |
| CFS and RFS instances | Service Inventory | SOM | — | TMF638. Each instance references its specification and its parent. |
| Resource instances | Resource Inventory | ROM | Network (EMS/NMS) | TMF639. The network itself is the final truth for configured state; inventory and network are reconciled, not assumed equal. |
In practice
Product catalogs are widely deployed; complete service catalogs are much rarer. Many estates model the product, then jump straight to resources, with the CFS and RFS logic held in workflow code inside the order or activation layer. The three-layer model then exists on slides only, and a technology change means editing workflows rather than adding an RFS specification.
Where the layers are modelled, the commonest drift is a CFS that names a technology ("GPON Internet"). It looks harmless, but it ties the product to the access network, and the next technology needs a new CFS, a new product mapping and often new offerings. Vendors also differ on where RFS lives: some service catalogs hold both CFS and RFS, while some orchestration products hold RFS in their own design environment. This is worth confirming early, because it decides who owns the decomposition rules.
The trade-off
What it solves
The product stays stable while the network changes: a new access technology is a new RFS, not a new product, and resources can be managed for capacity independently of what is sold.
What it does not solve
- Poor CFS design. A CFS that names a technology loses the isolation the layer exists to provide.
- Divergence between service inventory, resource inventory and the live network, which needs reconciliation whatever the model.
- The installed base, which was provisioned outside the model and has to be migrated into it.
What it adds
- Two more catalogs of specifications to design, version and govern, usually owned by different teams.
- An agreed boundary between CFS and RFS, which teams interpret differently unless it is written down.
- Order management must decompose across layers, so SOM and ROM need catalog-driven logic rather than fixed workflows.
Architecture decision
Should a new capability be modelled as a new CFS or as a new RFS under an existing CFS?
New RFS under an existing CFS
Choose when the customer experiences the same service and only the technical implementation differs, for example a new access technology.
New CFS
Choose when the customer experiences something different: a new feature, a different service level, or something they can order or fault separately.
Breaks if technology leaks into the CFS layer. Every network change then ripples up into product specifications and offerings, which is exactly what the layers were meant to prevent.
Takeaways
Key Takeaways
- CFS = what the customer experiences, technology-neutral
- RFS = how one technology implements a CFS; it is still a service, not a resource
- Resource = what is allocated on the network, physical or logical
- One CFS can decompose into different RFS sets, so the product survives a technology change
- Specifications live in catalogs; instances live in service and resource inventory
Check yourself
An operator moves broadband customers from copper to fibre. Which layers should change?Show answerHide
The RFS and resources beneath Internet Access. The CFS and the product should not change. If they have to, the CFS was carrying technology it should not have.
Is a VLAN an RFS or a resource?Show answerHide
It can be both, at different levels. A VLAN service that groups the behaviour of carrying customer traffic is an RFS; the specific VLAN ID allocated to one customer is a logical resource bound to that RFS.
A service catalog contains "Fibre Internet" and "Cable Internet" as separate CFS. What does that tell you?Show answerHide
Technology has leaked into the CFS layer. There is probably one customer-facing service, Internet Access, with two RFS implementations underneath it.