# The Next Generation Platform as A Service: Composition and Deployment of Platforms and Services
## 5 Virtual Network Function as A Service: Component RFBisation
### RFBisation of Services and Value-Added Services  
Following a similar approach to the RFBisation of the CORD platform, all services and VAS supported by the Telco PaaS have also been partially or fully RFBized and integrated into the NGPaaS workflow. With regards to the deployment of virtual Firewalls, Routers and monitoring probes two distinct RFB types are available. (1) Instance RFB, which deploys VM based services in the OpenStack environment of CORD; (2) Network RFB, which deploys networks in the Neutron environment of CORD. Using these two RFB types, complex deployment scenarios can be expressed by the VSP. Figure 14 illustrates an RFB graph comprising of three RFB groups: (I) Router (II) Firewall and (III) Probe and 5 RFB leaves (A) Router Instance (B) Firewall Instance (C) Probe Instance (D) Data Network and (E) Monitoring Network. Following the associations between the different RFB groups and leaves, this RFB graph will provide a service chain of a Firewall and Router VNF (through a commonly shared data network), in addition this graph also expresses that out of the two VNFs the Router is to be monitored by a probe, via the monitoring network. The side-car probes of the monitoring/healing infrastructure have been RFBised, while not available at this point, it is also possible to RFBise the remaining components (e.g., ELK stack, Healer). Additionally, the service provider can deploy service instances, networks and connectivity requests agnostically to the underlying technologies. It is the role of the NGPaaS OSS/BSS to translate these  
Figure 14: RFBisation of service deployment. Figure 13: RFBisation of the CORD platform via RDCL 3D. requests to the technology-specific APIs. More specifically for the case of the deployment of Figure 14, each of the leaf RFBs will be translated to a TOSCA recipe and then published to the TOSCA endpoint of the XOS orchestrator. Then XOS will decide how to serve this request best and translate this set of TOSCA recipes into API calls to OpenStack and ONOS. The API calls to OpenStack Nova will create the VM instances that will hold the router and firewall VNFs, while API calls to OpenStack Neutron will create the monitoring and data networks. Finally, through the dedicated REST API, XOS will instruct ONOS to populate the network with the necessary OpenFlow rules to facilitate connectivity between the VNFs. In the Telco PaaS, the VM images used to instantiate the VNFs have all been preconfigured with an SSH channel, which provides access to their CLI interface. This way any entity with access to the deployed VNFs (e.g., VSP, end user) could interface with them and configure them on demand, without the need to re-provision them. However, if more virtual resources are required (e.g., more vCPUs), then a new VNF deployment will be necessary using the NGPaaS workflow. The network policy framework has also been RFBised, thus allowing a VSP to either deploy policy type implementations in the policy framework or request for the enforcement of policy instances in the network. With regards to deploying the components of the policy framework only one RFB needed to be defined, namely the ONOSapp RFB. Deploying RFB graphs comprising of ONOSapp RFBs will result in the desired ONOS applications being installed and activated on the ONOS SDNC of the CORD platform. In Figure 15 (left), an RFB graph that requests the deployment of three ONOS applications is illustrated. These applications include the Policy Manager of the policy framework and two policy type implementations (Firewall and NAT). Once this RFB graph has been deployed, then the VSP can request the enforcement of Firewall and NAT policy instances. Following the example of Figure 12, the right side of Figure 15 illustrates an RFB graph that requests the enforcement of a Firewall policy instance. To facilitate the creation of RFB graphs of this type a collection of RFB types is available, one for each supported policy type (e.g., Firewall Policy Instance).