Keywords

1 Introduction

Nowadays Internet whose number of users approaches 2,7 billions [20], is massively used in all human activities from the professional part to the private ones via academical ones, administrative ones, etc. The infrastructure supporting the Internet services rests on various interconnected communication networks managed by network operators. This continuously growing infrastructure evolves very dynamically and becomes quite huge, complex, and sometimes locally ossified. To configure and maintain their communication networks and provide high-level services, network operators have therefore to deal with a large number of routers, firewalls, switches and various heterogeneous devices with a progressively reduced lifecycle due to the fast hardware and software changes. This growing complexity makes the introduction of a new service or a new protocol together with its configuration, an exceptionally difficult task, because network operators have to translate a high-level service specification to low-level distributed device configurations and next to configure these ones through their command line interface (CLI). This introduction have non trivial side effects leading to frequent network state changes for which operators have to adapt manually the existing network configuration to integrate the new services or protocols. As a result, this manual configuration may lead to frequent misconfigurations [16]. Last but not least, all these may have an adverse effect on the management cost of the operator (OPEX).

One of the main origins of the problem comes from the heterogeneous, decentralized and proprietary based control plane of the network. Indeed, each network device usually merges the control and the data plane in a proprietary box. Moving the control function out of the data plane element leads to an interesting two layer-based architecture. The potential benefits of such a separation have been explored in many previous studies. The 4D architecture [13], for example, separates completely an Autonomous System (AS) decision logic from the protocols governing the interactions among network elements. In this approach the routers and switches simply forward packets. This principle of decorrelating the control plane from the data one has indeed many advantages: it allows each one to evolve independently and with a high flexibility, moreover the vendor-agnostic control plane is programmable and provides a centralized network view. This approach leads to the development of a new promising network paradigm called Software Defined Networking (SDN) exploiting such a separation [17].

The main benefits brought by SDN rest on the centralized implementation of the entity managing the control plane which is usually called network controller [21]. Its interacting capabilities with the controlled network devices are done through the southbound interface (SBI) and have several advantages. Firstly, the programmability of the network straightforwardly follows from its centralized nature. It is clear that the introduction of new changes in the network through a program is easier than manually modifying the network using proprietary CLI of heterogeneous network devices. Secondly, observing the global network state, in a centralized way, allows the setting-up of precious knowledge exploited by the management program to optimize network traffic forwarding decisions. Nowadays, numerous commercial and non-commercial communities are developing SDN controllers, e.g. Controllers such as NOX [14], Beacon [12], Maestro [9], Floodlight [4], OpenDayLight [6]. It is worth noting that OpenFlow [19], proposed by Open Networking Foundation (ONF) [1], is the only standardized protocol implementing the SBI. Another interesting feature of the SDN concerns the capability to provide to third party applications an abstract view of the forwarding plane and of the network state. By interacting with different network devices, the controller may extract information and present through the northbound interface (NBI) an abstract view to network applications, such as load balancing and VLAN provisioning. This interface permits a rich synergy between the network and its applications. Network applications may conversely use the network abstraction to achieve the desired network behavior without knowledge of detailed physical network configuration. Supplying network information to the application, in order to reduce transition costs while improving applications performance, was proposed by the P4P framework [22]. In order to provide a network abstraction view, the IETF standardized a protocol for Application Layer Traffic Optimization (ALTO) [3]. The abstracted view is provided by the map of network regions and a ranking for connections between them. The work [15], also proposes the use of ALTO as a source of network topology and information to manipulate network state.

It is clear that, on one hand, an SDN based network management by significantly reducing the workload of network configurations, directly improves the operator’s OPEX and CAPEX (Capital expenditure). On the other hand, we argue that the full potential of SDN is far from being reached specially when considering the actually unexploited capabilities associated to the NBI. Indeed, in all the existing SDN controllers implementation [4, 6, 9, 12, 14] in order to make some modifications in the underlying network, an application (e.g. clients, orchestrators, admin, etc.) pushes some parameters via a REpresentational State Transfer (REST) interface into the NBI of the SDN controller. In order to govern the underlying network, existing controllers benefit a set of application blocks implementing basic network functions such as topology manager, switch manager, etc. To implement a service on an SDN based network, operators face a large number of controllers each one using a specific configuration work flow. This diversity of accesses to controllers through NBI prevents pooling processes which are fundamentally the same management tasks, if we consider them with the correct abstraction. It means that we finally moved from heterogeneous proprietary network devices to a miscellaneous SDN controllers world. It appears that providing a service abstraction on the top of the SDN controller may directly improve the network management. Nowadays, developing the right abstractions is one of the SDN challenges. This problematic has at our knowledge been once addressed by Tail-F who proposes a partial proprietary solution [10]. In order to reduce the Operation Support System (OSS) cost and also the time-to-market of services, Tail-F Network Control System (NCS) [2] introduces an abstraction layer on the top of the NBI in order to implement different services, including layer 2 or layer 3 VPN. It addresses an automated chain from the service request, on one hand, to the device configuration deployment in the network, on the other hand. This solution uses the YANG data model [8] in order to transform the informal service model to a formal one. The service model is mapped into device configurations as a data model transformation. The proposed work doesn’t however cover all management phases of the service lifecycle, specially service monitoring, maintenance, etc. Due to the proprietary nature of this product it is not possible to precisely analyze its internal structure.

We present in this paper a comprehensive solution to this problematic by identifying a reasonable set of capabilities of the NBI of the SDN together with the associated Application Programming Interfaces (API). Our first contribution rests on a global analysis of an abstract model of the operator platform articulated to a generic but simple service lifecycle, described in Sect. 2, which takes into account the view of the user together with that of the operator. Tackling the service lifecycle following these two sides simplifies the service abstraction design. The first viewpoint allows us to identify the APIs structuring the NBI and shared by both actors (operator and service consumer). By analyzing the second viewpoint we determine a model of the operator platform based on SDN which constitutes our second contribution. This platform model is abstracted through a framework involving a minimal set of functions required to manage any network service. We organize this set of functions in two orchestrators, one dedicated exclusively to the management of the resources: the resource orchestrator, and the other one grouping the remaining functions: the service orchestrator. The general framework structuring the internal architecture of SDN is presented in Sect. 3 and illustrated with an example. This framework is externally limited by NBI and SBI and internally clarifies the border between the two orchestrators by identifying an internal interface between them, called the middle interface. Finally, in the Sect. 4 we conclude the paper and outline some future works.

2 SDN Service LifeCycle Analysis

The ability of managing the lifecycle of a service is essential to implement it in an operator platform. Existing service lifecycle frameworks are oriented on human-driven services. For example, if a client needs to introduce or change an existing service, the operator has to configure the service manually. This manual configuration may take hours or sometimes days. It may therefore significantly affect the operators OPEX. It clearly appears that the operator has to re-think about its service implementation in order to provision dynamically and also to develop on-demand services. There are proposals in order to enhance new on-demand network resource provisioning. For instance, the GYESERS project [11], proposed a complex service lifecycle model for on-demand service provisioning. This model includes five typical stages, namely service requests/Service Level Agreement (SLA) negotiation, composition/reservation, deployment/register and synchronization, operation (monitoring), decommissioning. The main drawback of this model rests on its inherent complexity. We argue this one may be reduced by splitting the global service lifecycle in two complementary and manageable view points: client and operator view. Each one of both views captures only the information useful for the associated actor. The global view may however be obtained by composing the two partial views. We present below a detailed description of these two views together with the associated global view.

2.1 The Client View

Client-Side Service Lifecycle. The client-side service lifecycle is illustrated in Fig. 1. This service lifecycle consists of four main steps:

Fig. 1.
figure 1

Client-side service lifecycle

Full size image
Fig. 2.
figure 2

Client-side service control

Full size image

  • Service creation: The client specifies the service characteristics she needs, she negotiates the associated SLA which will be available for limited duration and finally she requests a new service creation.

  • Service monitoring: Once created, the service may be used by the client for the negotiated duration. The service consummation which concerns the client’s work-flow induces it’s monitoring with statistics production in order to control its exploitation.

  • Service modification: The client may request the modification of some parts of the existing service because of a new need. Its treatment is globally similar to the service creation request.

  • Service update: The management of the operator’s network may lead to the update of the service which can be issued because of a problem occurring during the service consummation or a modification of the network infrastructure. This update may be minimal or it may impact the previous steps, with consequences on the service creation and/or on the service consummation.

  • Service retirement: The client retires the service at the end of the negotiated duration. This step defines the end of the service life.

The Northbound Interface. The client-side service lifecycle is carried with interactions between the client’s service portal and the operator platform through the northbound interface (NBI). Our approach generalizes the classical SDN one where the NBI defines the interface which interconnects the client-side application with the SDN controller [17, 21].

Fig. 3.
figure 3

Operator-side Service lifecycle

Full size image

Figure 2 gives an overview of the communication between the service portal and the operator system through the NBI. This communication is divided in two main types: top-down and bottom-up, each one composed of requests acknowledged by responses or of notifications.

  • Top-down communication rests on a set of messages initiated from the service portal to the operator system. This message family includes service creation, modification, retirement and monitoring requests.

  • Bottom-up communication consists of a set of update notifications and update request messages initiated from the operator system to the service portal. An update notification allows to inform the client while an update request message should alter the current behavior of the service.

Figure 2 presents detailed steps of a generic call flow involving all the client-side service lifecycle.

  1. 1.

    In the first step the client requests a new service creation or a modification of an existing one. This step will ended with a response occurring when the service is implemented in the operator’s platform.

  2. 2.

    During the service consummation phase, the client may request the monitoring of the service. A service update initiated by the operator may also happen. If this update is minor it just leads to a service update notification. Otherwise, it may trigger a service update request sent to the client, as for example for an update of the operator’s network (software, hardware, etc.). The client acknowledges it with a service update response and initiates the service lifecycle from the beginning.

  3. 3.

    Finally, in the end of the service life, the client requests the service retirement.

The NBI will be implemented with help of an API distributed between the service portal and the operator system. The operator one’s is structured into two packages implementing service management control functions:

  • One package dedicated to implement service creation, modification and retirement functions and,

  • One package focusing on service monitoring functions.

The API located at the service portal consists of a single package that manages the service update functions. The analysis of this API is currently under progress. We will publish in a subsequent paper [7] an original and comprehensive specification of this API not resting on the REST paradigm.

Fig. 4.
figure 4

Operator-side Service Creation Call Flow

Full size image

2.2 The Operator View

Operator-Side Service Lifecycle. Figure 3 shows the operator-side service lifecycle which is composed in six main processes:

  • Service request: Once a service creation or modification request arrives from the user’s service portal, the request manager negotiates the SLA and service specification in order to implement it. It is worth noting that before agreeing the SLA the operator should ensure that the existing resources can cope with the requested service at the time it will be deployed. In case of unavailability, the request will be enqueued.

  • Service decomposition, compilation: The requested service is decomposed into several elementary service models which are sent to the service compiler. The compiler generates a set of network resource configurations which compose that service.

  • Service configuration: Based on the previous set of network resource configurations, several instances of corresponding virtual resources will be created, initialized and reservedFootnote 1. The requested service can then be implemented on these created virtual resources by deploying network resource configurations generated by the compiler.

  • Service maintain, monitoring and operation: Once a service is implemented, its availability, performance and capacity should be maintained automatically. In parallel, a service log manager will monitor all service lifecycle.

  • Service update: During the service exploitation the network infrastructure may necessitate changes due to some execution problems or technical evolution requirements, etc. It leads to update which may impact the service in different way. The update may be transparent to the service or it may require to re-initiate a part of the first steps of the service lifecycle.

  • Service retirement: The service configuration will be retired from the infrastructure as soon as a retirement request arrives to the system. The service retirement issued by the operator is out of the scope of this paper.

Illustrating Example. We describe the main processes through the example of a Virtual Private Network (VPN) service connecting three remote sites (assured by virtual routers: A, B and C) of a client connected to physical routers: R1, R2 and R3. The first step of the service lifecycle which consists in the “Service Creation” gives rise in the nominal case to a call flow the details of which are presented in Fig. 4. The service and resource management platform implements a service with the help of six functional units. In the first step, the client requests a VPN service and negotiates the service specifications, such as SLA, with the service request manager. Once the service specification finalized, the request manager sends the negotiated service model to the service decomposition/compilation unit. In our case the compiler will analyze the demanded service model and generate three configuration instructions (e.g. an instruction described in Extensible Markup Language (XML) or YANG data model [8]) used to configure each virtual router. The instruction will be sent to the service configuration unit in order to be executed on the virtual router. The resource reservation unit will be asked to initiate and reserve three virtual routers on physical routers: R1, R2 and R3 and open an interface between them and the service configuration unit. This interface can be instantiated by the help of the OpenFlow protocol [19], for example. Once the three virtual routers (A,B,C) are created, the service configuration unit can configure them in order to implement the demanded service. This unit can manage the virtual routers by the help of a remote configuration and management protocol (e.g. OF-Config [5]). Once the service is implemented, the service monitoring unit will be informed to monitor the service in its lifecycle. Finally the client will be informed about the service implementation through the request manager. As is mentioned previously the service portal will interact with the operator’s system through the northbound interface. The resource monitoring and resource reservation units manage the underlying physical resources via the southbound interface.

Fig. 5.
figure 5

Global service lifecycle

Full size image

2.3 The Global View

The global service lifecycle is the combination of two service lifecycles explained in Sects. 2.1 and 2.2. Figure 5 illustrates the interactions between these two service lifecycles. During the service run-time the client and the operator interact with each other using the NBI. This interface interconnects different phases of each part, as described below:

  • Service creation and Modification \(\leftrightarrow \) Service request, decomposition, compilation and configuration: the client-side service creation and specification phase leads to three first phases of the service lifecycle in the operator side; service request, decomposition, compilation and configuration.

  • Service monitoring \(\leftrightarrow \) Service maintain, monitoring and operating: client-side service monitoring, which is executed during the service consummation, is in parallel with operator-side service maintain, monitoring and operation.

  • Service update \(\leftrightarrow \) Service update: operator-side service maintain, monitoring and operation phase may lead to the service update phase in the client-side service lifecycle.

  • Service retirement \(\leftrightarrow \) Service retirement: In the end of the service life, the client-side service retirement phase will be executed in parallel with the operator-side service retirement.

3 Proposed Framework

In this section we propose to implement the operator-side lifecycle through two orchestration units. The “service orchestrator” will be dedicated to the service part (request, compilation/composition, configuration, maintain, monitoring, operation and retirement), while the “resource orchestrator” will manage resource reservation and resource monitor. The proposed framework is illustrated in Fig. 6. The model is composed of two main orchestration layers:

  • Service Orchestration

  • Resource Orchestration

Service Orchestrator (SO): This orchestrator has to receive service orders and initiate their establishment by decomposing complex service requests to elementary service models. These ones allow it to derive the type and the size of resources needed in order to implement that service. The SO will demand the virtual resource reservation from the lower layer and deploy the service configuration on the virtual resources.

Fig. 6.
figure 6

Proposed SDN framework

Full size image

Resource Orchestrator (RO): This orchestrator which manages physical resources, will reserve and initiate virtual resources on-demand. It maintains and monitors physical resources using southbound interface. The interface can be implemented by existing protocols/drivers, such as: onePK [18] and OpenFlow protocol.

The first orchestrator, SO, consists of four main functions as mentioned in Fig. 6. The request manager handles client’s service request and negotiates the service specifications, such as Service Level Agreement (SLA). A service can be an elementary service known by the orchestrator or a composition of several elementary services. The orchestrator will break-down all received service demands to one or several elementary service models. Once the elementary service model is produced, the service compiler will extract resource configurations needed to deploy that service. For example, in our case, described in Sect. 2.2, the compiler receives the VPN configuration, discovers virtual routers needed to implement that service and finally generates some configuration instructions (e.g. an instruction described in XML or YANG data model) used to configure the virtual routers. The service configuration unit is used in order to configure resources using these instructions. It may use a location database to find the appropriate router concerning the configuration. If a resource is missing the RO will be requested to initiate it by creating a virtual instance on the physical infrastructure. In the service run-time, the RO monitors and maintains the physical equipments that are hosting several virtual resources. It doesn’t have any perspective of running configuration of each virtual resource and it just keeps in mind the physical configuration to ensure the resource performance. If the RO faces an issue it will inform the problem to the SO that is consuming the resource. The service run-time lifecycle and performance is monitored by the SO. When it faces an upcoming alarm sent by the RO or a service run-time problem occurring on virtual resources, it will either perform some task to resolve the problem autonomously or send an alarm to the service consumer application.

Generally this framework contains three interfaces, one is the southbound interface which interconnects the RO to the physical infrastructure and the SO to it’s virtual resources. The second is the northbound interface which is used for service request and monitoring phases of service lifecycle. Inter-orchestrator (middle) interfaces which interconnect one SO to several ROs and vice versa may be used to implement a distributed orchestration architecture.

4 Conclusion

In this paper, we proposed a model of the NBI together with the associated API. The model is issued from a double sided service lifecycle which has been also used to define a SDN framework. This one structures in a modular way the internal architecture of the SDN in two orchestrators dedicated respectively to the management of services and resources. The proposed framework is externally limited by NBI and SBI and internally clarifies the border between the two orchestrators by identifying an internal interface between them, called the middle interface, which provides a virtual resource abstraction layer on the top the resource orchestrator. Our approach gives the foundation for the rigorous definition of the SDN architecture. It will be used to implement in a future work the NBI and the middle interface. It will help us to explore the distribution of the resource orchestrator.