## 4 Service-Oriented Approach for Dynamic Network Services
### Dynamic Service Chaining of Virtual Network Functions  
The deployment of network functions as VNFs paves the way for network resource and capabilities to be handled as independent and self-contained services that can be flexibly composed to provide a dynamically-established sequence of functionalities leveraging SOA principles, _i.e._, dynamic service chaining. In dynamic service chaining, the invocation flow of VNFs is specified at run time for addressing flexible and adaptive service deployments. We define as a \"Composite Service\" a generalized network service to be provisioned as a result of proper associations of VNF instances according to specified  
Figure 2: Service Oriented Architecture, Network Function Virtualization, and Software Defined Networking synergy for adaptive network service composition and delivery models. requirements. As depicted in Figure 3, the provisioning of a \"Composite Service\" through the orchestration of VNFs is enabled through the following functions: \"service composition specification and retrieval\", \"service selection\", \"service delivery\", and \"service placement\". The first two functions are typical of service-oriented architectures and are here slightly revisited to align with the terminology adopted in the VNF standard specifications. The latter two functions, instead, strongly depend on the peculiarities of reference service scenarios for network service chaining introduced in Section 3. Service composition specification consists in defining a chaining logic as a workflow of functional network capabilities, _i.e._, \"Abstract Service Chain\". More specifically, the \"Abstract Service Chain\" corresponds to the VNF-graph defined in ETSI [12] and specifies the types of VNFs that should be connected to provide a service (or part of a service), their order and the connectivity requirements among them (e.g., dependencies between VNFs, maximum latency and/or minimum bandwidth of inter-VNF connection, _etc._), while not specifying yet the location and implementation details of the instances that should actually provide those functions. When a service request has to be handled, the related service composition specification is retrieved. The \"Abstract Service Chain\" is thus a template for service chain instances. The level of abstraction thus introduced is essential to assure loose coupling between the exposed network service and the specific implementation and management issues of the VNF chain and its constituent elements. This promotes the flexibility to choose among available VNF instances at runtime (_i.e._, service selection), especially in a multi-provider environment. Furthermore, this level of abstraction eases the delivery of dynamically adaptable services to accommodate policy changes as well as requirements of clients accessing the service. Indeed, context-aware adaptation rules can be applied to modify at run time the \"Abstract Service Chain\" according to the current situation, e.g., user location and network load [11]. Service selection consists in the proper identification of the sequence of VNF instances among available candidates thereby mapping the \"Abstract Service Chain\" into a \"Concrete Service Chain\". Different algorithms can be used to this purpose that optimize a QoS-based utility function (e.g., minimizing the latency per-application traffic flows) for a given composition plan. Such algorithms can consider the computation capabilities and load status of resources executing the  
Figure 3: Service-oriented mechanisms for dynamic service chaining of Virtual Network Functions (VNFs). VNF instances, either deduced through estimations from usage historical data or collected through real-time monitoring data (_i.e._, context-aware selection).