Differences between CFS and RFS

Further to yesterday’s post about Service and Resource Availability, I received some questions about how to discern between CFS (Customer Facing Services) and RFS (Resource Facing Services) in relation to Fulfillment workflows. Then more specifically, how they relate to Service Order (SO), Service Order Manager (SOM), Product Catalog and Service Catalog solutions. Then finally how they relate to the orchestration or decomposition process.

I thought the following diagram, with a diagram showing decomposition from product, to CFS, to RFS, to allocation of resources might assist. This helps to describe the design-time element of Service Delivery. Design-time refers to how we set up the consistent, repeatable approach to end-to-end Service Order Management. We’ll talk more later about the run-time element of Service Delivery, which allows every single customer service request to be fulfilled / activated.

This diagram shows a hierarchical relationship / decomposition where:

  • Product – is the offering that a customer can buy, which may consist of one Customer Facing Service (or more). In the case of this diagram, the product consists of a physical bearer (the PON access) and the L3 VPN. This is the breakdown (or decomposition) of products to services
  • CFS (Customer Facing Service) – this is the service (or services) that the customer is paying the service providers for. The CFS is generally a high-level abstraction from any of the underlying infrastructure. It may have high-level Attributes such as throughput / bandwidth that describe capabilities that are common across various different network domains and infrastructure types. A CFS will generally map to one or more Resource Facing Service (a decomposed service from CFS into one or more RFS via decomposition rules or mappings)
  • RFS (Resource Facing Service) – this is the service that tends to relate to a specific domain (eg IP, SD-WAN, etc) or technology (eg different access types like FTTH, HFC, etc). These RFS are more likely to have Attributes that are more technology-specific including protocol-level details. Each RFS may then have the ability to allocate resources. An RFS could be singular / atomic in nature, or could actually be a composite of other RFSs 
  • Resources – these tend to be the objects (inventory entities) that are managed by Network / Resource Inventory Management solutions. These could be physical objects such as routers, or logical resource entities such as IP addresses. They could even be application-specific entities (as managed by element management systems [EMS]) or other reference data sourced from external systems such as site / location entities. Resource or Inventory components come in many different types.

Other important features of these hierarchical service configurations are:

  • Attributes – the parameters that are associated with each of the services at each different layer. These could be high-level abstract service specifications like class of service (COS), downlink rate (DL_RATE), or can be detailed resource specifications. Some attributes come from user-defined data (eg physical location, or address), whilst others are sourced from east-west systems (like the allocation of an IP address from an IPAM solution). Other attributes are allocated via reference data or orchestration rules
  • Service Mappings – this is the association of attributes or services. These hierarchy of mappings could allow customer data (such as bandwidth) entered in a customer portal or service order management tool to flow down through the service hierarchy to ultimately be pushed as an API parameter onto an EMS or network device. Or it could be a mapping between RFS to ensure that dependencies are properly enforced (eg in the diagram above, the VPN can’t be assigned unless there’s a physical bearer [ie PON Access] assigned first)
  • Orchestration Plans – these are the sequence of activities that allow the services, resources, attributes, dependencies and mappings are all carefully synchronised to reliably instantiate customer orders. The orchestration plan may include automated and/or manual activities or decisions or data-point collection

The orchestration plan is the important link between design-time and run-time activities. Design-time activities (including design of the orchestration plan) create the pattern of consistent service delivery for each product type. Run-time activities take the orchestration plan and implement that sequence for every customer order of that product type.

The run-time capability of a Service Order Manager should allow hundreds, or even thousands, of customer order activations (service instances) to be in-flight at any point in time. And not just for one product type and one orchestration plan, but for every product type the service provider offers. Each selected workflow is driven by a separate orchestration plan for each separate product type.

Note that the diagram above comes from this useful video:


For further reference, the following description sourced from TM Forum’s GB999 (Service overview sec 1.1.3), might help clarify the differences:

  • “This enables us to model a wide variety of services in a common class hierarchy while differentiating between Services that are obtained as a Product by a Customer versus those that aren’t. As we will see, a CustomerFacingService is one that is obtained as a Product by a Customer. Therefore, the Customer may have specific control over this Service via its associated Product. In contrast, the Customer never knows explicitly which ResourceFacingServices are being used to support a CustomerFacingService. More importantly, the Customer shouldn’t have to know which ResourceFacingServices are being used, since the Customer hasn’t explicitly obtained them.”
  • CFS are associated with resource technology neutral services i.e. they describe general capabilities and have attributes that are general across many technologies e.g. throughput, latency, SLA /loss rate, availability.
  • CFS and RFS typically have different lifecycles, CFS are related to customer and product changes and RFS to technology changes.
  • RFS are associated with resource technology specific services i.e. they have attributes that predominately relate to a specific technology.
  • RFS typically do some of the following:
    1. Map between the native protocols used to expose management of resources e.g. Netconf, YANG, SNMP, etc.
    2. Provide some integrated approach to provisioning and assuring RFS that span multiple technical domains e.g. slices across RAN and Core).
    3. They may be Operator, SP, ISV or Supplier provided.

Further important notes:

  • Composition of subordinate CFSs to support the CFSs exposed by Production capabilities (iterative composition pattern). These subordinate CFSs may be from other Operational Domains both within the same operator or acquired from third party operators as happens with wholesale interconnect.
  • Mapping of CFS to internal Resource Facing Services (RFS) that abstract into services the resource defined by Suppliers’ Technical Domains whose boundaries are defined by technology and supplier choices. This mapping links the boundary decisions of Operational Domains to the Technical Domain boundary decisions of suppliers.
  • RFSs can be atomic or composite to include other RFS (iterative composition pattern). This is a decision taken by the Operations / Integrator composing or creating RFSs based on deployment needs.
  • In a Service Oriented Architecture any exposed services can be consumed by any other service.

If this article was helpful, subscribe to the Passionate About OSS Blog to get each new post sent directly to your inbox. 100% free of charge and free of spam.

Our Solutions


Most Recent Articles

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.