NFV and SID

NFV and its sidekick SDN are getting a huge amount of attention and I’ve been wondering how these fit into good old Frameworx Information Model (SID).

There is a suggestion (http://blog.cimicorp.com/?p=2352) that NFV has been modelled as a Logical Resource at the bottom of the Resource stack by some NFV vendors and that surprised me and I'll explain why.

If you look at the acronym’s components, the word Function is, I believe, the key to understanding how NFV and SID fit together.
Let’s consider a Network Function such as "Firewall" which is often used as an example of something that NFV can deliver without having to deploy a dedicated “box” or firewall device.
I wonder, is it the firewall device that has been virtualised or is it the function that the device offers that has been virtualised? In this case is it that there is a virtual firewall device in the cloud or is the cloud providing a firewall service?

Network Elements are in the network to perform functions, or in SID terms provide services...
So a physical (actually, compound) resource such as a Juniper box provides the service of “Firewall”.
SID (used to) models Resource Facing Services being provided by Logical Resources installed on Physical Resources.

So is NFV/NVF just RFS in another guise?

Should Resource Facing Service (a terrible name see my blog "The Problem with RFSs") be renamed to Resource Functional Service to highlight the connection between NFV and RFS?

This blog was originally published on LinkedIn on 13 Oct 2015.

It has been pointed out to me by John Reilly, no less, that in the latest release of the Frameworx Information Framework (SID) that RFS is being dropped and is only in the release for backward compatibility.  RFS is being replaced by Config - perhaps I will comment on this in a future post.

The Problem with RFSs

CFSs are difficult to understand and have caused a huge amount of debate in the TMForum Community and beyond, but RFSs that lurk beneath CFSs are even less well understood.

A recent training and consulting assignment to a telco in Canada revealed a number of issues that they had with RFSs and I suspect many other people have similar problems.

The first issue was the name - Resource Facing Services.  "Resource Facing" makes it sound as if the RFSs provide services to the Resources in the same way as the "Customer Facing" services provide services to the "customer" (or rather User, so perhaps CFS should be renamed UFS, but that's another story). But RFS providing services to Resources doesn't make a lot of sense!  If we have a set of services made up of CFSs on one side and RFSs on the other each servicing its own community and the RFS are supporting the CFSs - what provides the Services themselves?  The problem lies in the name Resource Facing Service and in particular the word "Facing"; it is the wrong word.  A better name would be "Resource Exposed Service" or "Resource Hosted Service" or "Resource Provided Services" or "Resource Fronted Services" (to preserve the acronym) as these types of service don't "Face" the Resources, rather they are exposed or provided by the Resources.

My view is that the RFSs are services that run "in the network" (or perhaps in the end user device, if you are talking about a smart phone or advanced set-top-box).  I think of them (and they used to be defined in SID) as interfaces or Services implemented by software running on hardware.

A second issue, that took me a little while to understand when talking to this group of enthusiastic Canadians, was that they were erroneously assuming that the RFSs (at least, if not CFSs as well) were objects involved with the provisioning of a Product on the network.   This I assured them was not correct.   The Service is the service used when using the Product, not the provisioning process used to create a Product in the network.

A third issue was how to describe the provisioning process for RFSs.  Logically you provision a Product by breaking it down into its components - Resources that the Product delivers (i.e. CPE - so we provision by Logistics delivering (and optionally Workforce management installing the

resource) or by giving the resource to the customer in the shop) and CFSs which we provision decomposing the CFSs into RFSs and provision those on the network... 

But, I hold that you don't usually directly provision RFSs.  With intelligent Network Elements you pass commands (Resource Orders?) to the NE and it internally does some magic in its "black box" to provision the RFS, and therefore from a provisioning perspective we can (usually) ignore RFSs.

Nevertheless when provisioning we need to understand how a CFS decomposes into RFSs and which "boxes" in the network support/provide these RFSs but practically we can jump from CFS Spec (via the RFS Spec) straight to Resources that deliver the RFSs.  Practically we rarely provision a CFS or RFS directly (I guess the exception might be something like a VPN where the service has a number of parameters that can be altered after the VPN has been created, but again I would argue this is done by talking to (a) a supervisor service or application (Logical Resource) that manages the VPN or (b) a VPN "box", or resource that provides the VPN (front end).

So, RFSs are as tricky as CFSs - someone recently asked me why we bother with these Services and I replied that before them things were even trickier.  The SID has really helped Communications Service Providers describe their products in very generic manner using CFSs and RFSs.