## 5 Architectural Design
Indeed, it can be decomposed into two main functional components, also according to ETSI MANO specifications: (i) VNF Manager(s), which in accordance with the instructions received by the \"Service Orchestrator\", initiates or terminate VNF instances or modifies the existing configuration and (ii) virtual infrastructure manager(s), which manages the lifecycle of virtual resources, such as virtual machines and containers. Both components collect monitoring information on the VNFs and resources operational status and performance metrics (Table 1) and notify the \"Service and Function Registry\" when events of interest occur (e.g., unavailability of a VNF instance). Figure 4: Functional architecture for adaptive service composition and delivery. The \"Network Resource Control\" FE is in charge of setting up and managing the network links required to connect the VNF instances. It handles the requests originated from the \"Service Orchestrator\" FE for connecting a set of (newly) instantiated VNFs for new (or modified) service contracts by properly enforcing the forwarding rules in the network devices along the delivery path. More specifically, the \"Resource Discovery\" FE handles the discovery of resource capabilities and network topology thus enabling routing, path computation and traffic engineering decisions. The \"Resource Provisioning\" FE handles low-level configuration directives to addresses the programming of the network nodes based on information provided by the \"Resource Discovery\" FE and under the coordination of the \"Service Control\" FE to consistently steer data flows through the desired VNF chain. The \"Resource Monitoring\" FE handles low-level directives for network monitoring (_i.e._, collection of traffic statistics) to feed the \"Network Context Server\" FE, which is in charge of collecting the network topological and dynamic information of VNF links and making it available to the \"Services and Functions Registry\" FE with the proper level of abstraction and granularity. More specifically, it handles the descriptive and operational information of links connecting VNFs (Table 1). Efforts for defining VNF and VNF link data models are on-going both in ETSI [12] and in IETF [44] standardization bodies. The \"Network Resource Control\" FE and the \"Network Context Server\" FE can be identified within the IETF ABNO architecture. Specifically, the \"Network Context Server\" FE refers to the IETF Application-Layer Traffic Optimization (ALTO) server [45] while the \"Network Resource Control\" FE mainly refers to the ABNO controller. The ALTO server is envisioned to provide abstract network topology information on an end-to-end basis (e.g., network location structure, topological distance between locations and cost between them) for allowing applications to take decisions about service deployments. Relevant network costs information is, for instance, the maximum bandwidth, minimum cross-domain traffic, and lower cost to the user. The ABNO controller is the main component of the ABNO architecture [13] and is responsible for orchestrating the workflows among ABNO components (e.g., path computation element, topology managers policy agents, and provisioning manager) while addressing application requests of end-to-end network services, e.g., point-to-point path between specified endpoints. Moreover, the ABNO controller is envisioned to provide dynamic network performance information to applications, such as bandwidth usage, available capacity and end-to-end delay.