NaaS architecture through SDN-enabled NFV

Transcription

1 NaaS architecture through SDN-enabled NFV Network openness towards Web Communication Service Providers Amina Boubendir Orange Labs / Télécom ParisTech Issy-Les-Moulineaux, France amina.boubendir@orange.com Emmanuel Bertin Orange Labs Caen, France emmanuel.bertin@orange.com Noëmie Simoni Télécom ParisTech Paris, France noemie.simoni@telecom-paristech.fr Abstract The sharp rise of OTT application services in recent years has called for greater application-to-network visibility. These dynamic application services represent a foremost drive in the communication ecosystem changes. However, the tight coupling between network services and network infrastructures pose challenges for network providers. They need more dynamicity in their network architectures to meet the requirements of application services. SDN and NFV is the combination of networking technologies that facilitate such an evolution. But is it sufficient to allow dynamic application-to-network interactions? In this paper, we rely on SDN-enabled NFV assets as a strong foundation to propose a dynamic and adaptable Network-asa-Service architecture. We leverage our NaaS proposal with a resilient Network Exposition Layer allowing to express offers and demands of network services. To demonstrate the offered features, we propose three architecture deployment models: broad, customized and event-based dynamic model. We then instantiate our architecture within the WebRTC-based communication services, illustrating the collaboration between network providers and Communication Service Providers (CSPs). Index Terms SDN, NFV, Network-as-a-Service, network exposition, dynamic deployment, OTT, CSP, WebRTC. I. INTRODUCTION The continuous evolution at the application layer with Over- The-Top (OTT) services push users to expect ubiquitous access to network services, from any device, via any access network and with specific requirements of Quality of Service (QoS). With these variations in customer demands, application services are raising challenges in Telco network infrastructures. They reshape application-to-network communication models. Indeed, the tight coupling between network service functions and network infrastructures induces a silo service model in which each type of network service is supported by specific infrastructure capability. This makes current Telco architectures ill-suited to meet the dynamic requirements of these application services. So, today s networks are closed and monolithic. They allow neither Telcos nor OTTs to choose the most suitable network service needed by applications and even less to provide it dynamically and on-the-fly. Therefore, it becomes vital for Telco networks to gain higher dynamicity in offering network services in order to achieve Network-as-a-Service. Nonetheless, this objective implies the need for networking technologies enabling dynamicity and /16/$ European Union the need for network exposition tools enabling application-tonetwork visibility. For that, we consider both Software-Defined Networking (SDN) [1] and Network Functions Virtualization (NFV) [2] technologies as key opportunities to achieve network dynamicity being based on decoupling service logics from hardware infrastructures. Thus, in NaaS context, their combination is essential to allow both network adaptability and dynamicity as they provide capabilities to perform both efficient network policies enforcement according to applications requirements, and dynamic network service deployment which enables the on-demand aspect of NaaS. We will show that relying on SDN-enabled NFV [3] and introducing a network exposition layer (network service description, discovery and composition tools), are two essential elements to define a NaaS architectural model that allows Telcos to offer their network services dynamically to thirdparty actors using different deployment approaches. In the following Section, we survey some related work. Next, we emphasize SDN-enabled NFV strengths and role as a foundation for dynamic and adaptable NaaS. In Section IV, we describe in detail our proposal of NaaS architecture and focus on the importance of a Network Exposition Layer, then propose three architecture deployment models. Section VI illustrates NaaS through Telco-CSPs interactions where we consider WebRTC services and propose network functions that Telcos would offer dynamically using the deployment models. II. RELATED WORK To deal with the dynamic provisioning of networking services in the context of network openness, [4] is an ongoing work to propose SDN-aware NFV and [5] has proposed A Flexible NFV Networking Solution using OpenFlow-enabled SDN for the NFV deployment. Also, T-NOVA project [6] has proposed a framework for providing network functions as a service and UNIFY project [7] has proposed a unified programmability framework. The work in [8] has proposed Operator Network Monetization Through Openflow-Enabled SDN promoting SDN to enable symbiotic linkage between operator s network and applications. However, none of these works consider SDN-enabled NFV as the main enabler for NaaS. This related work shows a clear momentum for exploiting SDN-enabled NFV for the networking part of NaaS and thus facilitate the advance towards NaaS.

2 III. SDN-ENABLED NFV: A RESILIENT FOUNDATION FOR DYNAMIC NAAS ARCHITECTURE In this Section, we describe the benefits of integrating SDN by NFV as SDN-enabled NFV for NaaS. Later, we extract limitations of SDN-enabled NFV architecture and additional requirements in the objective of achieving a NaaS architecture. A. SDN-enabled NFV: enabler for dynamic NaaS SDN technology gains in maturity and NFV becomes a real technological trend. In addition to SDN and NFV inherent benefits, how would Telco networks integrate both technologies features to achieve NaaS with desired dynamicity? As SDN and NFV become important in order to build flexible networks, the need for automation and for management operations from one part, and the need for dynamicity in service deployment and life cycle management from another part, are primary requirements for NaaS. NFV allows flexible service deployment and hardware independency as it targets the placement of software-defined functions over virtualized infrastructures. However, NFV does not specify the networking logics between the functions to deploy. Unlike SDN, it has no knowledge of the network state. Based on the centralized network control, SDN allows efficient network policies enforcement using network abstractions and programmability. It provides automated network control and management and a dynamic realization of data plane functions. But SDN does not indicate the deployment of these functions over VMs, while NFV does. Also, the SDN infrastructure is to be virtualized like an NFV Infrastructure (NFVI) to embrace more network processes as SDN network services are network-related while NFV embraces a larger range of functions through the NFVI and with different orchestration levels. This way, considering SDN-enabled NFV is full of promise for both integrating SDN and NFV as a basis for NaaS to gain from their dynamicity. B. SDN-enabled NFV: a way forward Although SDN-enabled NFV is a strong enabler for dynamic NaaS, there is space for innovation in this area, and SDN-enabled NFV should evolve beyond providing a network infrastructure with enhanced capabilities dynamically deployed to an open framework where these enhanced capabilities and value-added network functions are customized and offered as a service to network users. While SDN-enabled NFV advocates mainly the deployment of Virtualized Network Functions (VNFs) using SDN networking features; the agility, scalability and dynamicity offered by this integration do not directly address the limitations related to enabling interactions between network providers and OTTs in the NaaS paradigm. In order to offer access to the value-added network functions, Telcos need to create and publish catalogs of network functions, network services and network policies. But for them to offer these value-added network functions towards OTTs, is yet another issue which we propose to address in the rest of this paper through a NaaS architecture model and the concrete case of WebRTC services. IV. DYNAMIC NETWORK AS-A-SERVICE ARCHITECTURE In this Section, we describe our proposal of dynamic NaaS architecture then define three deployment models for the NaaS architecture that demonstrate the features of this architecture. A. Dynamic Network-as-a-Service Architecture Automation, programmability and dynamic deployment offered by SDN-enabled NFV are key mechanisms to dynamically offer attractive network functions to application service provides (OTTs). Figure 1 synthesizes our NaaS architecture model proposal. This NaaS model is structured based on two important components that we detail in the following. 1) A Network Exposition Layer: In order to achieve the network openness aspect of NaaS, it is important to support a Network Exposition Layer to allow visibility between applications and the network. On Figure 1, the exposition layer is built on top of the platform that holds the VNFs to expose. This layer is the enabler for achieving a NaaS architecture. The NaaS exposition Layer includes a Service Description module that represents a registry through which the network provider publishes structured descriptions and references of the (virtual) network functions and services that he wishes to expose. The Service Description module is connected to a Service Broker which is composed of Service Discovery and Service Composition modules. The Service Discovery module allows third-party actors (OTTs) to access the service registry and submit service requests by performing service selection. The Service Composition module is then responsible for achieving composition of network functions, if needed, to build the requested network service then returns the composition result. The interaction between the network provider and OTTs is either at the management layer through OSS BSS based on pre-established Service Level Agreements (SLAs) or at the orchestration layer dynamically between application services and network applications. Fig. 1: Dynamic Network-as-a-Service Architecture

3 2) Software Network Infrastructure: In order to achieve the networking-level and infrastructure-level adaptability and dynamicity, the Software Network Infrastructure of the proposed Naas architecture is based on SDN-enabled NFV. First, the NFV Infrastructure (NFVI) comprises a set of virtualized resources providing computing, storage and network capabilities controlled and managed by Virtualized Infrastructure Managers (VIM). NFVI resources are located in NFVI-PoPs in the form of distributed data Centers deployed close to end-users using a structural asset Telcos have as network providers, i.e, their local presence near end users. This advantage guarantee an at-the-edge service deployment for faster service request handling and lighten loads over the network which reduces cross-network delays to improve overall QoS. SDN represents a part of the NFVI and precisely in the infrastructure network domain as it provides connectivity services. At the intermediate level, VNFs run on top of one or several NFVI resources and the VNF Manager (VNFM) handles VNF lifecycles (on-boarding, instantiating, monitoring, terminating and deleting) and is responsible for controlling and managing VNF resources. Moreover, the SDN centralized control plays a big role in VNF chaining aspects to build NFV services. An NFV service is built based on a combination of VNFs using VNF Forwarding Graphs (VNF FGs). The SDN controller implements virtual network segments to chain the VNFs and build the NFV network service. Also, requirements like adaptable elasticity, scalability and resources mobility are fulfilled by SDN capabilities. To scale up or down the network, the SDN controller programs the network using policies to cumulate or segregate ingress traffic and then, directs the traffic to be processed by particular VNFs. In addition, the SDN control plane programmability and the NFV dynamic service deployment allow together to modify a VNF chaining based on the requested network service. The NFV Orchestrator (NFVO) controls and manages infrastructure services. It coordinates the resource allocation to infrastructure services and VNFs, either by a direct interaction with the VIM or via the VNF Manager. It takes into account deployment policies based on various criteria including affinity rules, location constraints and performance criteria. SDN controller interacts with the VIM and the NFVO using SDN northbound APIs. The NFV orchestrator and network applications go through the VIM to program the networking control functions of SDN controllers through northbound APIs. The SDN controller, through southbound API, is in charge of applying network rules and forwarding policies over the network devices in the NFVI. The NFVI-PoPs include virtualized resources and are interconnected by the transport network. Thus, the software network infrastructure of the NaaS architecture has characteristics of software-centric, network adaptablity, network control dynamicity, programmability, network service deployment dynamicity and automation in network management. We further describe the proposed architecture through the following three deployment models. B. Proposed Architecture Deployment Models We propose three deployment models for the NaaS architecture introduced in this paper and discuss technical aspects of each deployment. Each of these deployments shows the added dynamicity and illustrates the NaaS architecture features. 1) Broad Deployment Model: Broad deployment suggests that network functions be deployed over the NFVI of a network provider as always-on VMs. This means that the VNFs representing these functions are instantiated over VMs of NFVI-PoPs in a constant manner and act functionally as Physical Network Functions (PNFs). However, the fact that these functions are VNFs, offers the network provider the agility to rapidly deploy them without the need to buy new vendor equipment and go through long-cycle on-site physical intervention for installation and configuration processes. SDN controller programs the flow processing of media traffic going through these VNFs. This deployment model is a placement of VNFs over the desired NFVI-PoP location of the NFVI. The advantages of this deployment model are directly linked to the advantages brought by SDN-enabled and NFV. 2) Customized Deployment Model: This deployment model is used when the network provider is willing to customize the broad deployment only for some specific OTT clients. It means that the operator deploys specialized network services in a customized manner only for OTTs that have requested and concluded an SLA. Both actors go through service brokering procedures in this case. Based on OTT choices, the NFVO asks the VNFM to deploy only the desired network functions. In this deployment scenario, there is a need for identifying the users of the OTT application service that has agreed on an SLA with the network provider. This deployment strategy is a way of monetizing network functions and services. It includes the benefits of the previous one and represents a basis for a tailored Telco-CSP collaboration. 3) Event-based Dynamic Deployment Model: In this model, OTTs benefit from a differentiated orchestration and specialized network services offered by Telco in an on-demand dynamic way. OTT applications request a specialized network function or service from network applications included in the orchestrator. The NFVO relays the request to the VNFM who is in charge of the VNF placement and life-cycle management, the VIM then decides of the most adequate NFVI-PoP for deploying the VNFs and achieves resource and operation management. The decision is made based on the end user location in the network which might be known by a core network functions (e.g., SDN controller or a user location database). Finally, the SDN controller is invoked through its northbound API to apply desired networking policies and processes to transport the application flows using its southbound API. V. ILLUSTRATING USE-CASE: TELCO NETWORK FUNCTIONS FOR WEBRTC USING NAAS ARCHITECTURE In this Section, we consider WebRTC communication services as a case of study to our NaaS architecture proposal.

4 A. OTT-CSPs Needs at Network-level Web Real-Time Communication (WebRTC) [9] allows versatile browser-to-browser audio and video communications, screen sharing and data exchange (e.g., for instant messaging or file transfer). WebRTC clients can communicate using any device, on any type of access networks and be provided by various service providers. This way, WebRTC is fostering the need for application-to-network visibility. In addition to the need for adaptable networks, application service providers need special network services. Indeed, in a previous work [10], we have identified the needs of CSPs at a network-level in Telco-OTT collaboration context. These needs arise from WebRTC services shortcomings and are mainly linked to: 1) Guarantee of QoS at a network-level: CSPs rely on application-level mechanisms for QoS guarantee but media flows benefit only from best-effort routing in the network [11]. 2) Need for network interoperability: As Telcos rely on IMS for Voice and video services, there is a need for bridging web and Telco signaling to enable a CSP s caller to join a callee on the Telco telephony service. 3) Need for media relays: Network architecture implementations do not allow direct P2P WebRTC communications (mode 1) for addressing and security reasons and peers are behind NATs, Proxies or Firewalls. For that, Interactive Connectivity Establishment (ICE) [12] is used for middleboxes traversal to ensure a functional media path between WebRTC clients. However, ICE mechanism, see Figure 2, needs STUN (Session Traversal Utilities for NAT)and TURN servers (Traversal Using Relays around NAT) to solve NAT traversal (modes 2, 3) [13]. We have concluded that CSPs have service limitations that Telcos know how to deal with. Therefore, we present next the Telco network functions that best address them. B. Value-added Network Functions for WebRTC services We first present value-added network functions to answer these CSPs WebRTC limitations then show how NaaS architecture enables Telcos to deploy these specific network functions dynamically and on-demand based on CSPs needs. 1) Virtual QoS Gateway: Regarding WebRTC QoS limitations, we propose a virtual QoS Gateway (QoS vgw) that Fig. 2: WebRTC Connection Modes will be invoked by WebRTC clients or CSP WebRTC server with a specific QoS request or if a better QoS is needed. It will be deployed as an interface between CSP WebRTC servers and the Policy and Charging Rules Function (PCRF) (Figure 3) as PCRF is responsible for policy-making and control decisions in the LTE core network. It provides QoS information to the S/PGW, initiates dynamically a dedicated bearer with requested QoS level, enforces QoS parameters, determines charging policy and finally manages and controls data sessions when WebRTC media flows are initiated. Fig. 3: QoS Gateway for WebRTC 2) Virtual Trunking Gateway: We propose that Telcos offer a Virtual Trunking Gateway that would be in charge of converting the signaling and transport protocols used in WebRTC control and media planes (HTTP, SRTP, SCTP, DTLS,...) to Session Initiation Protocol (SIP) in Telco IMS world. Fig. 4: Trunking Gateway for WebRTC 3) Virtual STUN and TURN servers: As part of raising the percentage of successful P2P connections, WebRTC specifications call for a TURN server to be available. We have explained earlier, the importance of STUN and TURN for WebRTC connections. Providing STUN and TURN servers is then a key role for Telcos in the collaboration perspective with CSPs. Our proposal here is to virtualize STUN and TURN servers as virtualized network functions. Each of these value-added network functions are provided as VNFs and using the NaaS architecture network providers will be able to dynamically deploy them over the software network infrastructure on-demand. Indeed, to illustrate the event-based dynamic deployment, we consider a request from a WebRTC application. The application invokes the NFV Orchestrator which asks the VNF manager then the VIM to instantiate TURN VNF. The Service Composition module would build for instance a network service composed of load balancer and TURN VNFs. The effective service function chaining would be achieved through virtual links by the SDN controller after instantiating the selected VNFs.

5 VI. CONCLUSIONS & FUTURE WORK This paper introduces a Network-as-a-Service architecture with a focus on the dynamicity and adaptability features offered by SDN-enabled NFV at the networking level and the network openness offered by the Network Exposition Layer. It opens ways of achieving agile network-to-application interactions through the proposed architecture deployment models. We have applied this work to WebRTC services to target Communication Service Providers but it is extendable to other types of OTT services, like content distribution services. After having established the bases for adaptable and dynamic NaaS architecture and defining the most important Network Exposition modules through this architecture proposal, the flexibility in network functions composition is a future work we target to investigate. In this respect, we focus our work on the software architecture of virtual network functions and their modeling in a form of service-oriented components and deeply define accordingly network service description, discovery and composition operations in the NaaS architecture. ACKNOWLEDGMENT We would like to thank Mr. Bruno Chatras and Mr. Philippe Fouquart from Orange Labs Networks for their useful remarks and valuable help upon writing the paper. REFERENCES [1] D.Kreutz et al., Software-defined networking: A comprehensive survey, in Proceedings of the IEEE, vol. 103, pp , Jan [2] B. Han, V. Gopalakrishnan, L. Ji, and S. Lee, Network function virtualization: Challenges and opportunities for innovations, Communications Magazine, IEEE, vol. 53, pp , Feb [3] J.Matias et al., Toward an sdn-enabled nfv architecture, Communications Magazine, IEEE, vol. 53, pp , April [4] ETSI NFV ISG, SDN usage in NFV, Available on: [5] ONF, Solution Brief, OpenFlow-Enabled SDN and Network Functions Virtualization, February [6] G. Xilouris, et al., T-nova: A marketplace for virtualized network functions, in Networks and Communications (EuCNC), 2014 European Conference on, pp. 1 5, June [7] P. Skoldstrom et al., Towards unified programmability of cloud and carrier infrastructure, in Software Defined Networks (EWSDN), 2014 Third European Workshop on, pp , Sept [8] ONF, Solution Brief, Operator Network Monetization Through OpenFlow-Enabled, April [9] C. Jennings and al., Real-time communications for the web, Communications Magazine, IEEE, vol. 51, pp , April [10] A. Boubendir, E. Bertin, and N. Simoni, Network as-a-service: The webrtc case. how sdn and nfv set a solid telco-ott groundwork, in Network of the Future (NOF), th International Conference on the, pp. 1 3, Sept [11] E. Janczukowicz, S. Tuffin, A. Braud, A. Bouabdallah, G. Fromentoux, and J.-M. Bonnin, Approaches for Offering QoS and Specialized Traffic Treatment for WebRTC, vol of Lecture Notes in Computer Science, pp Springer International Publishing, [12] IETF, Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols. [13] A. B. Johnston and D. C. Burnett, WebRTC: APIs and RTCWEB Protocols of the HTML5 Real-Time Web