One of the obvious questions relating to Service Function Chaining (SFC) is how does it differ from the traditional model of creating a sequence of functions (FW/IPS, ADC, vWAN, Router), whether in specialized hardware or dedicated VMs, and passing traffic between those functions in a switched data plane? While that model could be considered to be a service chain, it lacks two qualities that bring the maximum possible benefit to a service chain: automatic scaling and optimal pathing through the service chain. A simple high level definition of a service function chain (SFC) is that an SFC is the ordered (though not necessarily static) set of functions needed to provide a given service. While there is much discussion about basing these SFCs on Virtual Network Functions (VNF), ideally all classes of network functions could be accommodated by the SFC framework. Typically the four classes of network functions include:
- Traditional fixed function dedicated appliances (e.g. a dedicated Next Gen Firewall appliance)
- Augmented COTS hardware (e.g. a COTS server augmented with a PCIe network processor card)
- Fixed function COTS (e.g. a vendor provides a COTS box with certain functions pre-installed and qualified)
- Elastic COTS (e.g. a COTS server with sufficient resources to host a “scalable” set of VNFs)
(1.) Must be accommodated to utilize existing assets. (2.) Must be accommodated to address performance requirements that exceed what a reasonable COTS platform(s) can provide. (3.) Enables vendors to provide a pre-validated set of functions that will provide a stable and predictable (set of) functions. (4.) Provides a VNF framework that can scale up/down, in/out, and be flexibly located within the network.
In principle, an SFC could be constructed from any mix of the four elements above. The emerging standards encompass the different mixes at a high level. However, there is one common element that applies in all cases: the existence of a centralized controller that has enough built-in intelligence to know how to construct these chains and gives the ability to create, deploy, and scale multiple instances of these chains without manual intervention once the topology has been created.
That centralized “controller” is assumed to exist and enable the benefits in the discussion below. Details of that controller will not be covered but it is assumed that in can provide the needed services. Secondly the most compelling benefits are provided by class (4.) and that will be the focus of what follows.
Dynamic Service Function Chains
One way to look at the “dynamic” nature of SFCs composed of elements of class (4.) is consider two aspects: the first is “scaling” (out/in, up/down) and the second is to look at dynamic paths through the SFC.
The conventional definition of scale out/in is to add/remove resource instances to accommodate need.
Scale up/down implies the modification of a resource to accommodate need. In the context of a service chain this could be extended to include the introduction of specific resource types (e.g. introduce a new function into the service chain during a DDOS attack as opposed to just adding more elements to absorb the traffic increase).
One of the compelling features of an SDN/NFV-enable network is to be able to respond to peak demand for services (cell phone service at events such as the Mobile World Conference is a frequently used example). In order to provide this response more resources need to be pulled in during the demand spike and released back into a service pool once that spike has passed. While this could be done, in principle, by manual intervention the cost and complexity of that intervention is prohibitive.
What sort of events could trigger scaling in a service chain? For scale out/in, in a fully automated environment, the load on the elements in the service chain is monitored and resources automatically added (scale out) or removed (scale in) to accommodate the current load. Alternatively a customer might request a higher quality of service for a specific period of time or event via a customer portal. Here new resources might not be pulled into the service chain but changes to the parameters of the service chain would result in the dynamically provisioned user being given priority over “best effort” users.
To illustrate a scale up/down scenario taking the DDOS reference above, consider a virtual CCAP (Converged Cable Access Platform) that might control as many as 6000 DOCSIS downstream channels. It would be uneconomical and logistically complex to instantiate more of these platforms to respond to a DDOS attack. It would be more efficient to redirect attack traffic to devices that could accommodate the attack load effectively.
In any of these scenarios the resources could be distributed (limited by interconnection capacity) and with the existence of the centralized controller, scaling can be enabled across locations.
In our next blog post, we’ll look at “dynamic pathing” and at an example on how the capacity of the SFC to (auto) scale and (auto) path provides valuable benefits not realizable with static physical device chains.