## 6 Architecture Preliminary Validation via Prototype
### SDN Orchestrator  
The software design of the SDN orchestrator is shown in Figure 6b. More specifically, a subset of the \"Service Orchestrator\" functions is implemented in the request manager, the service data delivery control and coordination and the adaptation module. In fact these blocks handle requests for the establishment of data delivery paths throughout a specified set of middlebox services. These blocks leverage the basic network server (BNServer) and the Floodlight components that implement the \"Network Resource Control\" functions. As a result of interactions between the above blocks triggered by path set-up requests, a consistent set of forwarding rules can be enforced across network nodes in order to steer service data flows through the desired VNF chain. In addition to the ordinary workflow for the setup of a new request, the data delivery path set-up requests can be also generated by other SDN orchestrators for the establishment of paths to be concatenated to other paths in a multi-provider scenario or by other internal blocks as a result of an orchestration process to adapt established paths to modified network status. The forwarding rules are enforced in the network nodes via the south-bound interface (SB-I) through the OpenFlow protocol [47]. Moreover, these blocks put in place adaptation mechanisms to cope with degradation events. In fact, degradation events are likely to occur as a result of concurrent usage of network node capabilities among multiple services and the prototype allows for reactively adapting loads across network nodes while addressing required data delivery performance. To this purpose, the prototype also includes \"Network Context Server\" functions implemented by the statistics collector block, which collects, elaborates, and aggregates OpenFlow statistics about network nodes and links (e.g., switch throughput computed from per-port byte counters), while making them available with the proper level of granularity in internal databases acting as \"Service and Function Registry\". More specifically, such databases contain descriptive information (e.g., IP addresses of end-points, identifier and port number of intermediate network nodes) as well as operational data about the data delivery (segment) paths established throughout the network realizing (part of) running service chain instances, e.g., delay on a per-chain basis. Such data are elaborated by the adaptation module that is in charge of triggering the service data delivery control and coordination block for the adaptation of (part of) service paths throughout different set of switches (_i.e.,_ redirection) as soon as a degradation event is detected (e.g., switch load exceeding a certain threshold).  
Without lack of generality, the only orchestration and adaptability at the level of the data service delivery path is addressed by the SDN orchestrator prototype. The adaptability also at the level of VNFs and the respective lifecycle management via a cloud management platform is considered as future work. Further details on the prototype design, functional blocks and implementation can be found in [48].