Virtualizing network services the telecom cloud

Transcription

1 The communications technology journal since Virtualizing services the telecom cloud March 28, 2014

2 The telco cloud 2 Virtualizing services the telecom cloud Inspired by a transformation in neighboring industry sectors toward providing information, products and functions as services XaaS the telecommunication industry is evolving the architecture of its systems and s. This new generation of architecture is characterized by a very high degree of abstraction and virtualization. HENRIK BASILIER, MARIAN DARULA AND JOE WILKE The demand for bandwidth created by subscribers and devices has been rising steadily for a number of years. The amount of data carried by mobile s is doubling roughly every year 1, and the number of connected machine-to-machine (M2M) devices sensors and actuators is expected to reach 50 billion by However, average revenue per user (ARPU) is declining in most markets, and the price point for connectivity for many M2M devices is low. The subsequent catch-22 situation where infrastructure growth is needed to meet increased demand in the face of hard-pressed revenue margins is a significant innovation challenge for the ICT industry. Traditional telecom product development is deeply rooted in standards, BOX A Terms and abbreviations ADC API ARPU BFD DMTF EPC M2M NF NFV NIC NOC ONF OSPF application delivery controller application programming interface average revenue per user Bidirectional Forwarding Detection Distributed Management Task Force Evolved Packet Core machine-to-machine function Network Functions Virtualization interface card operations center operations, administration and maintenance Open Networking Foundation Open Shortest Path First protocols and service quality a model that has served the industry well, until recently. But the situation has changed. Increased competition, the perceived high cost of proprietary hardware and the need for reduced complexity in design has led to the formation of the Network Functions Virtualization (NFV) consortium. Simplified operation of virtualized platforms and hardware-independent functionality are just some of this group s aims 2. The benefits offered by next generation systems include rapid deployment of new services, ease of scalability and reduced duplication. These systems are primarily being built with mass-market technologies that capitalize on virtualization and cloud techniques to manage resources in terms of their storage, computational and ing needs. Virtualization and the technologies related to it, such as cloud orchestration, OSS OVF SAF SBG SDN SLA TCO VDC VLAN RP WAN XaaS operations support systems Open Virtualization Format Service Availability Forum Session Border Gateway software-defined ing Service Level Agreement total cost of ownership virtual data center virtual local area virtual machine virtual function virtualized router Virtual Router Redundancy Protocol wide area anything as a service carry the transformational power that is needed to reap the benefits offered by higher levels of abstraction. Modern virtualization technologies, such as software-defined ing (SDN), in combination with existing tools for storage and computing, ensure virtualization and abstraction for the entire set of critical resources. The general aim of SDN and NFV is to deliver functions, s and infrastructure as services rather than as features of vertically integrated systems. This enables operators to offer communication services at the right price points for subscribers, by serving the next generations of terminals like high-end smartphones, tablets, and 3D glasses. In addition, this enables operators to offer low-price connectivity to service providers of M2M communication, by supporting devices like utility meters and health care equipment. The nature of telecoms today The setup for telco applications tends to be quite sophisticated, and there are a number of factors that contribute to this complexity, including: the need for security zoning; overcoming addressing constraints; the requirement for a high degree of statefulness, which in turn creates needs for load balancing and mechanisms to ensure high availability; as well as the way standards have been defined and legacy implementation choices. Telco applications often require multiple VPNs and virtual local area s (VLANs), subnets with additional routing, as well as sophisticated load balancers, firewalls, address translators, transparent proxies, and QoS/policybased routing. The process to integrate all of these elements is often both static

3 3 and manual, which is time consuming and leads to inaccuracies. Being able to integrate elements automatically, through say automatic orchestration with SDN technologies, is a vital step in the creation of new generation systems that will reduce time to market for the deployment of new services and increase operational flexibility. FIGURE 1 The real-time telecom cloud Cloud tenants, virtual data centers (VDCs), telco s Benefits and cost For operators, the return on investment associated with migrating services to the cloud comes in the form of reduced TCO, improved TTM and a very high degree of automation in operation all of which improve the bottom line. To guarantee continued service, a migrated environment needs to provide all ing capabilities, as well as ensure the interworking and portability of telco applications. To keep costs down, the impact of migration on applications should be kept to a minimum however, with some application adaptation, it is possible to further take advantage of the automation and elasticity offered by cloud and virtualization technologies. This article describes the requirements placed on telco applications as a result of increased abstraction, as well as the challenges a telecom cloud must overcome (including migration), and how these challenges differ from the general IT cloud. The article also gives some insight into the implementation aspects of the telecom cloud, what kind of services, APIs and capabilities are expected, and what technologies will be used. The telecom cloud An operator can be described as a set of solutions, such as EPC or IMS/ VoLTE, split over multiple organizational domains. In turn, these domains consist of sets of telco applications that interconnect using site infrastructure, such as switches, routers, firewalls and transport s. When a is deployed virtually, organizational domains within the operator becomes a tenant of the shared cloud infrastructure, which provides virtual data centers (VDCs) that serve as resource containers and zones of isolation. Operator solutions are deployed in Telco solutions and applications VDCs and telco applications and nodes become telco virtual functions (s) implemented as portable containers for multiple virtual machines (s). As illustrated in Figure 1, the cloud infrastructure fulfills the interconnect capability along with other infrastructure requirements that are provided by site infrastructure and transport s in non-virtualized environments. Interconnectivity needs to be maintained between virtualized and nonvirtualized s, and domain managers for telco solutions (OSSs) need to be able to manage dedicated infrastructure as well as virtual resources. Telco systems and applications place tough demands on the ing capabilities of cloud infrastructure. This is because the requirements of telco systems are much more stringent and varied than generic IT applications. Typical telco systems need support for: multiple routing contexts and routing protocols; multiple VPN connections to external s; packet-load-balancing capabilities for heavy payload applications including additional capabilities than are typically included in application delivery controllers (ADCs); support for virtual interface cards (NICs) to trunk large numbers of VLANs and interconnect to external Transport Cloud infrastructure(s) s; path diversity; service chaining for bump-in-the-wire applications; security zoning; heavy-duty routing between tenant s; geo-redundancy mechanisms; and latency/qos control. In traditional s, these features are provided by the site infrastructure. In the telecom cloud, these features need to be replicated by the cloud infrastructure in such a way that they can be orchestrated, as orchestrated features can be exposed through appropriate abstractions, as well as being coupled with advanced support for discoverability and traceability. In a cloud infrastructure, the concepts of multi-tenancy and separation of concerns are crucial, as they enable organizations (tenants) to securely share the same space and manage their own virtual resources implemented as isolated slices of the physical resources (VDCs in other words). Isolation and separation are required by all functions and API components. For tenants, cloud computing is ultimately about increasing flexibility, reducing complexity and time to market, as well as improving cost-efficiency. Providers of cloud infrastructure services can help tenants to achieve

4 The telco cloud 4 FIGURE 2 Multi-tenant cloud architecture Tenant 1 Tenant domain manager Telco VDC Cloud infrastructure domain Telco these goals by providing generic abstractions of services with a high degree of automated life cycle management for resources. To manage the complete life cycle of application-layer functions contained in VDCs and s, each tenant needs to provide the domain-manager functionality that is specific to their solution domain. This manager interacts with the cloud infrastructure domain that manages the life cycle for virtual resources, it maintains descriptions of VDCs and s, interacts with the cloud orchestrator for resource creation/assignment/deletion, as well as integrating with application-specific management. To take advantage of the elasticity that cloud computing provides, to, for example, scale out operations or direct control, the application layer needs to adapt to real-time changes VDC management Cloud orchestrator Cloud infrastructure Data center Tenant 2 WAN Tenant domain manager Domainspecific life cycle management Domainspecific life cycle management Data center Telco VDC in resources. Descriptors of VDCs and s exchanged with the cloud infrastructure serve as a contract between the two responsibility domains, and may also include SLAs. A virtual data center is a managed collection of computational, storage and ing slices provided to a tenant by the cloud infrastructure from its pool of resources which may be distributed across a set of data centers. Resources assigned to a given tenant are isolated from other tenants, but can be interconnected through external s and other VDCs. The tenant determines how this interconnection takes place on the basis of their security policies. As illustrated in Figure 2, tenants can deploy solutions within a VDC as a set of interconnected telco s. For internal and external ing purposes, each tenant is required to supply descriptions of all Telco External s their telco s, as well as of the solution/vdc level. To automate the allocation of all the requested resources, the cloud infrastructure uses what is commonly referred to as orchestration technologies. If WAN connectivity is needed for orchestration, it is provided by an underlying transport domain. The basic ing capabilities provided to a tenant through the VDC construct can range in complexity from very basic L2 links to multiple s with intra-routing. Advanced capabilities, such as firewalling, load balancing and service chaining can be ordered as resources within a VDC. From the tenant perspective, all resources are virtual and fully isolated. Although SDN control can be exposed to the tenant (for service chaining purposes, for example), such control is restricted to isolated slices of the under the management of the tenant SDN controller. To connect to other VDCs or another outside the cloud infrastructure, the data center needs to be connected to the internet or to a private VPN. The need for external connectivity should be described by the tenant in the form of connection points at the edges of the VDC. Authorization of the requested connectivity is granted by the cloud orchestrator, which (as part of the orchestration process) also configures the actual routing/switching functions that connect s within the data center to the outside. One of the aims of the telecom cloud is to automate this part of the process. Service establishment Setting up a telco service or solution inside the cloud involves a number of steps, which can be summarized as: onboard instantiable descriptions/ templates of the telco s; onboard instantiable descriptions/ templates of the VDCs; instantiate the virtual data center in which the cloud orchestrator allocates resources for shared use within a VDC; instantiate the desired telco s within the VDC the cloud orchestrator allocates the resources needed for the and binds them to the VDC; and configure the application-specific elements of the telco s. Once a service is established, it enters

5 5 service assurance mode, where the ability to both observe and trace the requested VDC and s is key. Automating orchestration To be able to automate processes through orchestration, a number of service establishment descriptions are needed, including: descriptions of the telco, specifying its needs, such as computational, storage and ing resources along with start order instructions; descriptions of other services and resources required by the cloud system, such as firewalling and load balancing; descriptions of the ing requirement for the VDC as a whole, including internal connectivity among s as well as external connectivity, which includes definitions of service chains. For automated orchestration to work, essentially everything that in the past was configured manually must now be made into machine-readable description formats. To guide the orchestration of resources, these descriptions also include SLA-related parameters, such as affinity/anti-affinity rules and latency requirements. As illustrated in Figure 3, the relationships between the different types of descriptions need to be managed. A telco (and its constituent parts) needs to connect with s inside and outside the virtual data center. As such, they define the logical connection points that the VDC ing description needs to resolve into s defined within the VDC description. Likewise, the VDC descriptor needs to refer to logical connection points to (VDC or) external s, which the cloud domain manager resolves into real connections. To support elastic operations such as scale out, with flexible and automated deployment of s and VDCs, their descriptors (the VDCs and s) should be viewed as templates for all resource assignments. As such, the containing VDC defines the context for a instance and scale out s use the descriptor as a template. The cloud infrastructure uses the descriptions provided by the tenant to orchestrate virtual s as well as all other resources. Virtualized FIGURE 3 Logical connection points in VDC ing Telco 1 Telco 2 Internal VDC execution (tenant view) LBaaS Infrastructure Managers (such as OpenStack) orchestrate resource requests across multiple sites and layers of functionality, using SDN controllers to create virtual connections derived from the provided descriptions. Automating deployment internal VLAN VLAN 1 CSCF 2 VDC VDC 3 Cloud edge Cloud edge aas External transport WAN External VPN 2 External VPN 1 To automate deployment of telco s in virtual data centers and to reduce the effort required to support deployment in different virtualized target environments, applications should be made available and packaged in a hypervisor-neutral virtual-machine file format preferably the Open FIGURE 4 An example of telco realized as a of s accommodating multiple logical fucntions I-CSCF 4 S-CSCF/BGCF I-CSCF Scalable distributed system Application layer signaling VLANs S-CSCF 5 6 BGCF

6 The telco cloud 6 FIGURE 5 Connectivity and transport solution among telco s Virtualization Format (OVF) specified by the Distributed Management Task Force (DMTF). When deploying telco solutions, the set of OVF files containing deployment instructions is ingested by the cloud manager orchestration function, and the solution is deployed accordingly. Similarly, the VDC needs to be described in a format that is suitable for automation. Both descriptor levels need to encompass all applicable ing. Telco applications in the cloud A cloud-based ing solution needs to support QoS to guarantee telecom quality and real-time behavior, and at the same time it needs to be flexible to automate deployment and connectivity within the implemented as a for scaling. An application implements a logical function, and its interfaces are defined by standards like 3GPP and IETF. Telco s accommodate one or more logical functions and are usually designed to be used by large numbers of subscribers and to support heavy traffic loads. Scalable capacity is a fundamental part of telco application design, and implementation typically uses RP architecture. This applies to traditional (non-cloud) deployment as well as deployment in a virtual data center. In the virtual environment, the software of a telco runs on a set of (OS-inclusive) virtual machines (s). A telco built on a ed architecture can be dimensioned to fit expected capacity by deploying the right number of s. The application, however, is exposed as a single entity on a level, hiding internal structure from the surroundings and thus providing a manageable solution with low opex. Such an architecture allows the telco to be scaled dynamically to fit traffic conditions, where scaling can be achieved by adding or removing members. As such, the virtualized solution provides obvious advantages when scaling can be achieved by simply turning a on or off. The entire cloud deployment needs to be optimized from a transport and storage perspective, so that, for example, an increase or decrease in available resources automatically generates a corresponding adaptation of transport layer bandwidth and storage capacity. Proper operation of a telco Application signaling VPN VPN requires reliable, secure and high performance intra- communication as well as communication with neighboring s. This is implemented by adopting L2, VLAN and IP-VPN technologies in the VDC. To separate the communication for different trust domains, s use different VLANs. To start with, there is one VLAN for communication among the s within the telco ; one VLAN for operations, administration and maintenance () communication between the telco and the OSS/ operations center (NOC); and one VLAN for application layer communication among the functions (NFs) in the IMS architecture. In addition, some telco s, such as Session Border Gateway (SBG), communicate with users and other operators; such s require an additional VLAN per access domain and per interconnect. For security and L3 load balancing reasons, IP routers are used for communication among telco s there is no direct VLAN connectivity between telco s. This concept is illustrated in Figure 5. The best solution for virtual data centers is to deploy nodes together with virtualized routers (s). s host router functions and serve different traffic types, such as application signaling or. s one per security domain are used by telco s to communicate with each other and externally. s support Open Shortest Path First (OSPF), Bidirectional Forwarding Detection (BFD) and link load balancing for the telco as well as forwarding filters. The complete solution, including s, can be described by, for example, an evolved OVF description, enabling automatic deployment without the need for any manual correction. Quality remains the same Traditional telecom s are designed to provide uninterrupted service and a superior user experience. The high availability and real-time characteristics of telco applications supported by related infrastructure capabilities are key capabilities that help operators achieve their targeted levels of service and QoE, and these targets are the same for both traditional and virtual

7 7 environments. However, virtualization poses additional challenges that need to be overcome. Telco s typically include built-in support for resilience, such as availability support in core middleware based on OpenSAF. Consequently, certain rules need to be taken into consideration when deploying telco s in a virtualized environment. For example, it s not a good idea to deploy all s on the same hardware, as a hardware failure would cause complete node outage. Such deployment rules can be specified in OVF, so that correct deployment is performed when a cloud manager ingests the OVF file during initial deployment. Telco applications can in turn make the most of features provided by the infrastructure to, for example, maintain availability. For example, s can be automatically restarted on different hardware in the event of a failure. FIGURE 6 NFV reference architecture NFVI OSS/BSS EMS 1 EMS 2 EMS 3 1 Virtual computing Computing hardware Service, and infrastructure description 2 3 Virtual storage Vn-Nf Virtualization layer Virtual Vi-Ha Hardware resources Storage Network hardware hardware Os-Ma Se-Ma Ve-Vnfm Nf-Vi NFV management and orchestration Orchestrator manager(s) Or-Vnfm Vi-Vnfm Virtualized infrastructure manager(s) Execution reference point Other reference point Main NFV reference point Or-Vi Industry movements A wide variety of organizations, such as ETSI NFV, OpenStack, OpenDaylight, DMTF, ONF and IETF, are involved in the industry shift to cloud-deployed solutions. For operators, ETSI NFV has a more prominent role as a result of its development of overall frameworks and architectures and attention to telecomspecific requirements. NFV was established as an industry consortium to ensure alignment within the telecom segment, enabling operators to deploy functions in an automated way on state-of-the art computational and storage entities. Such a move from vertically-integrated purpose-built systems to high-scale generic hardware is an attractive one for operators, as it results in more homogenous systems, reducing the costs associated with complexity and proprietary hardware. This ability to replace static and manual configuration, including operations such as cabling, will be an important capability of efficient future systems. This is reflected in the NFV reference architecture, which is illustrated in Figure 6 as the NFV management and orchestration domain. From the management and orchestration domain, reference points connect the layers in the non-management FIGURE 7 IMS core example CUDB MTAS icscf HSS scscf IP works N-SBC MRF A-SBC LBaaS BGF LBaaS VPN aas FWaaS FWaaS FWaaS OM GRX Access

8 The telco cloud 8 FIGURE 8 Multi-tenant multi-instance IMS in VDC NOC Tenant 1 Tenant 2 Access Access SBG Core Central storage Storage DC switch FW domain, which contains: a support systems layer (OSS/BSS), a layer representing the virtualized functions, and a third layer (NFVI) that represents the infrastructure containing both virtualized and physical resources. In the near future, ETSI NFV requirements will be translated into appropriate standards. Example case IMS An IMS core is based on standardized interconnected logical functions whose operation in a virtual data center would be supported by additional infrastructure-related functions such as firewalling and load balancing. Figure 7 illustrates an example IMS core. Cloud deployment creates the possibility to implement multiple instances of IMS core s to serve different tenants by utilizing the multi-tenant capability of the cloud infrastructure. The set of telco s that implements a given tenant s IMS core is deployed in the VDC dedicated to the Tenant 1 Tenant 2 CSCF CSCF HSS MTAS PGM Tenant 1 IMS HSS MTAS PGM Tenant 2 IMS tenant. An example of such deployment is illustrated in Figure 8. Tenants are deployed over a shared cloud infrastructure in which the ing solution guarantees tenant separation fulfilling security requirements and fair use of resources. As Figure 8 illustrates, the requirements placed on the cloud infrastructure are complex. Advanced VLAN handling for telco s is required as is path redundancy, the ability to cope with large numbers of VLANs for SBG access, interconnect for multiple enterprises, and routing and complex interconnect with legacy s/vpns and all of these requirements not only need to be implemented, they also need to be automated. The functionality provided by the virtual data center needs to cover all of these aspects, on top of providing true tenant separation, realtime performance, geographical distribution and telecom-grade availability. Automation and dynamicity are key elements to providing a cloud offering as a service based on an IMS core. A VDC can be instantiated from a description on IDNS IDNS MFRP Signaling Media MFRP Signaling Media demand, resulting in tenant s being created or modified. Interconnect is established automatically by the infrastructure using orchestration and SDN technologies. The domain manager for the IMS application is responsible for these steps, as well as all other life cycle management, including, for example, runtime scale out operations. Conclusion Traditional architecture is often built on proprietary hardware. Telecom systems are by nature vertical inseparable towers that become overly complex and are as a result costly to operate. Spearheaded by the IT industry, a shift toward providing everything as a service is taking place. Adopting a similar approach for functions is one way for operators to expand infrastructure. Some of the benefits of this type of transformation are: reduced complexity which lowers running costs; simplified in and out scalability which makes efficient use of resources and supports dynamic ability to respond to changes in capacity demand; and reduced time to market for new services. In addition to enabling new benefits and opportunities, the cloud infrastructure must ensure the robustness, performance, security and interoperability for telco applications, minimizing the costs induced by the transformation itself. This requires a system that provides telco apps with a smooth transition and real-time fully telecom-adapted support, while providing new sets of enablers that act as a bridge to a new era of cloud-empowered telco applications and solutions. References 1. Ericsson, November 2013, Mobility Report, available at: ericsson.com/res/docs/2013/ ericsson-mobility-reportnovember-2013.pdf 2. ETSI, NFV role and activities, available at: org/technologies-s/ technologies/nfv

9 9 Henrik Basilier To bring you the best of Ericsson s research world, our employees have been writing articles for Ericsson Review our communications technology journal since Today, Ericsson Review articles have a two-tofive year perspective and our objective is to provide you with up-to-date insights on how things are shaping up for the Networked Society. Address : Ericsson SE Stockholm, Sweden Phone: Publishing: Ericsson Review articles and additional material are pub ished on: www ericsson.com/review. Use the RSS feed to stay informed of the latest updates. Ericsson Technology Insights All Ericsson Review articles are available on the Ericsson Technology Insights app available for Android and ios devices. The link for your device is on the Ericsson Review website: review. If you are viewing this digitally, you can: download from Google Play or download from the App Store Publisher: Ulf Ewaldsson Editorial board: Håkan Andersson, Hans Antvik, Ulrika Bergström, Joakim Cerwall, Deirdre P. Doyle, Dan Fahrman, Anita Frisell, Jonas Högberg, Patrik Jestin, Magnus Karlsson, Cenk Kirbas, Sara Kullman, Börje Lundwall, Hans Mickelsson, Ulf Olsson, Patrik Regårdh, Patrik Roséen and Gunnar Thrysin Editor: Deirdre P. Doyle deirdre.doyle@jgcommunication se Contributors: Paul Eade, Nathan Hegedus and Ian Nicholson Art director and layout: Carola Pilarz Illustrations: Claes-Göran Andersson ISSN: Volume: 91, 2014 is an expert at Business Unit Networks. He has worked for Ericsson since 1991 in a wide area of subjects and roles. He is currently engaged in internal R&D studies and customer cooperation in the areas of cloud, virtualization and SDN. He holds an M.Sc. in computer science and technology from the Institute of Technology at Linköping University, Sweden. Marian Darula is head of Network Transformation at Development Unit Core Networks, Architectures and Technology. He is currently leading the technology project for telecom s transformation adopting cloud technologies and NFV. He holds a Ph.D. in theoretical electronics from the Institute of Electrical Engineering, Slovak Academy of Sciences, Bratislava, Slovakia and a degree in applied mathematics and software engineering from Czech Technical University, Prague, Czech Republic. Joe Wilke is head of Development Unit IP & Broadband Technology Aachen and currently manages the technology leadership program for virtualization and cloud. He holds a degree in electrical engineering from the University of Aachen, Germany and a degree in engineering and business from the University of Hagen, Germany.

10 Ericsson SE Stockholm, Sweden Phone: ISSN Uen Ericsson AB 2014