Internet Research Task Force (IRTF) R. Krishnan Internet Draft Brocade Category: Experimental Dilip Krishnaswamy IBM Research D. R. Lopez Telefonica I+D Peter Willis BT Asif Qamar Evolv Expires: December 2014 July 21, 2014 An Open NFV Architectural Framework for Virality Based Content Caching draft-krishnan-nfvrg-open-nfv-virality-00 Abstract One of the key goals of Network Functions Virtualization (NFV) is achieving energy efficiency through workload consolidation. A good example for maximizing energy savings is the Virtualization of Content Delivery Networks (vCDNs) NFV use case where the video streaming workloads exhibit significant difference between prime- time and non-prime-time usage of the infrastructure. This draft examines the practical challenges in maximizing energy efficiency for vCDN workloads. This draft proposes an open NFV architectural framework for conveying content virality information from Cloud applications such as YouTube, Twitter and mechanisms for leveraging it to maximize the energy efficiency for vCDN workloads. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents Krishnan Expires April 2014 [Page 1] Internet-Draft Open NFV Virality Content Caching September 2013 at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April, 2014. Copyright Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. Table of Contents 1. Introduction...................................................3 2. Open NFV Architectural Framework...............................4 3. System Analysis................................................6 4. Open API Parameters............................................7 4.1. Content Virality Information..............................7 4.2. Other Application Information.............................7 5. Summary........................................................7 6. Future Work....................................................7 7. IANA Considerations............................................7 8. Security Considerations........................................7 9. Acknowledgements...............................................7 10. References....................................................7 10.1. Normative References.....................................7 10.2. Informative References...................................7 Authors' Addresses................................................9 Krishnan Expires April 2014 [Page 2] Internet-Draft Open NFV Virality Content Caching September 2013 1. Introduction Network Operators use a variety of proprietary hardware appliances. Hardware appliances, though deliver performance, are complex to manage, not easy to scale up/down in capacity and not cost effective. NFV [1] is a movement by network operators all over the world such as AT&T, BT, CenturyLink, Deutsche Telekom, Telefonica, Verizon, and more to address the aforementioned issues. NFV involves the implementation of network functions in software that can run on a range of industry standard server hardware, and that can be moved to, or instantiated in, various locations in the network as required, without the need for installation of new equipment. NFV has many use cases [2], notable of which is the vCDN. The goal of vCDN would be to address virtualization of all the CDN components, but the biggest and immediate impact would be on the cache nodes given the growth in content especially in mobile networks [3]. The key benefits of vCDN are . Overall capacity is shared by all content delivery appliances and other virtualized appliances. . Since appliances are pure software, it is easy to replace or modify them in the event of new CDN requirements. . Besides caching of operator's own content, this enables operators to offer content caching as a service to CDN providers (e.g. Akamai Aura CDN) and large content providers with private CDNs (e.g. Netflix OpenConnect). Currently, the allocation of VMs for vCDN follows a static model based on weekday prime-time characteristics, business hours etc. This model results in substantial resource over-provisioning, since a lot of content viewed over websites like YouTube and shared over social media like Twitter follow a virality pattern during anytime of weekday or weekend [4]. Additionally, many industry standard servers consume substantial power in the active idle state, which results in severe energy inefficiency. For example, HP ProLiant DL380p Rack Server has a peak power utilization of 324 Watts and consumes 105 Watts (approximately 30% of peak) in the active idle state - this is depicted in Page 17 of [5]. One of the key goals of Network Functions Virtualization (NFV) is achieving energy efficiency through workload consolidation [6]. This draft proposes an open NFV architectural framework for conveying content virality information from applications such as Twitter, Krishnan Expires April 2014 [Page 3] Internet-Draft Open NFV Virality Content Caching September 2013 Facebook, YouTube and mechanisms for leveraging it to maximize the energy efficiency for vCDN workloads without compromising performance. This enables network operators to offer new types of content caching services to its CDN customers for example, "Virality Based Content Caching" and also optimize the resource usage of their own CDNs. This draft also does a performance comparison of the proposed approach with the current static model of allocation of VMs for vCDNs and demonstrates the benefits of the approach. 2. Open NFV Architectural Framework Figure 1 depicts the Open NFV Architectural Framework, adapted from the definition of the ETSI NFV Architectural Framework [7] and extended in this draft to show support for content virality management. It has the following virtual and physical or hardware (HW) infrastructure components as part of NFV Infrastructure (NFVI) 1) Compute - physical servers hosting computing elements in the form of Virtual Machines (VMs) 2) Storage - physical/virtual storage 3) Networking - physical/virtual routers. The Virtual Infrastructure Manager (VIM), which could be accomplished by open source software like OpenStack [8] for example, performs lifecycle management of the above infrastructure components and maintains a dynamic resource pool of the same. Virtual Network Functions (VNFs) such as firewall, load balancer, CDN etc., each of which runs on multiple VMs, are managed by Virtualized Network Function Manager (VNFM), which performs lifecycle management of VNFs and maintains dynamic resource pool(s) for different types of VNFs. The VNFM exchanges Virtual/Physical resource information with the VIM. The other elements of the NFV architectural framework include a service orchestrator, and management and support systems such as an Element Management System (EMS), an Operations Support System (OSS), and a Business Support System (BSS). Krishnan Expires April 2014 [Page 4] Internet-Draft Open NFV Virality Content Caching September 2013 Content Virality Information -------------------------------------- OPEN API (RESTful etc.)- NFV Boundary -------------------------------------- | | | NFV Architectural Blocks | | (Virtual Network Function | | Manager - VNFM) | -------------------------------------- Figure 1: Open NFV Architectural Framework (Adapted from [7]) The various interfaces in the Open NFV architectural framework are - Vi-Ha - Interface between the virtualization layer (e.g. hypervisor for hardware compute servers) and hardware resources - Vn-Nf - Represents the execution environment provided by the NFVI to VNF (e.g. a single VNF could have multiple VMs) - Nf-Vi - Interface to the VIM - used for VM lifecycle management and other purposes - Ve-Vnfm - Interface between VNF/EMS and VNF Manager - used for VNF lifecycle management and other purposes - Se-Ma - Used for getting information about VNF deployment template and other purposes - Os-Ma - Interface to OSS/BSS - handles network service lifecycle management and other functions. - Vi-Vnfm - Interface between VIM and VNFM - handles resource allocation requests by the VNF manager and other functions Krishnan Expires April 2014 [Page 5] Internet-Draft Open NFV Virality Content Caching September 2013 - Or-Vnfm - Interface between Orchestrator and VNFM - handles collection of state information necessary for network service lifecycle management and other functions To support content virality information in this open architecture, we suggest the availability of such information through open APIs as depicted in Figure 1. The open API can be based on RESTful framework [9] [10]. Content virality information can be streamed in real-time from applications such as YouTube, and submitted to the VNFM through open APIs. This information can be used by VNFM to populate the dynamic vCDN resource pool with the optimal VNF capacity needed for content caching which can be consolidated to a minimal set of VMs and physical servers. Besides content virality information, we also suggest that the architecture could optionally provide a generic open API framework for handling other application information, such as information regarding firewall services, in real-time if available. In typical current systems, the vCDN resource pool is statically populated by policies such as weekday prime-time characteristics, business hours etc., and can be significantly over-provisioned to handle any dynamic requests. Current systems also do not delve into specific targeted use cases or a framework for conveying application information in real-time. The rest of the contribution of this draft is to develop these aspects further in an open architecture framework as suggested in Figure 1. In effect, the differentiating aspects of the proposed architectural framework in this draft are - A dynamic resource pool that is used to optimally populate the vCDN VNFs with the right amount of VMs and physical servers to minimize over-provisioning. - Parameters of interest for real-time streaming of application information such as content virality, which could be utilized for resource optimization in an open-API framework. 3. System Analysis This work is in progress in ETSI NFV as a proof of concept [11]. More details will be described in the upcoming revisions of this draft. Krishnan Expires April 2014 [Page 6] Internet-Draft Open NFV Virality Content Caching September 2013 4. Open API Parameters 4.1. Content Virality Information TBD 4.2. Other Application Information TBD 5. Summary This draft proposes an NFV architectural framework for conveying content virality information from Cloud applications such as YouTube, Twitter, Facebook and mechanisms for leveraging it to maximize the energy efficiency for vCDN workloads without compromising performance. More - TBD 6. Future Work TBD 7. IANA Considerations This draft does not have any IANA considerations. 8. Security Considerations Security issues may arise due to the usage of open APIs for exchanging content virality information. These security issues apply to all forms of open APIs and not limited to exchange of content virality information. This is an aspect for further detailed study. 9. Acknowledgements None. 10. References 10.1. Normative References 10.2. Informative References [1] "ETSI NFV White Paper," http://portal.etsi.org/NFV/NFV_White_Paper.pdf Krishnan Expires April 2014 [Page 7] Internet-Draft Open NFV Virality Content Caching September 2013 [2] "ETSI NFV Use Cases," http://www.etsi.org/deliver/etsi_gs/NFV/001_099/001/01.01.01_60/gs_N FV001v010101p.pdf [3] "Cisco VNI White Paper: Global Mobile Data Traffic Forecast Update," http://www.cisco.com/en/US/solutions/collateral/ns341/ns525/ns537/ns 705/ns827/white_paper_c11-520862.html, February 2014 [4] "Facegroup: How Videos go Viral," http://www.facegroup.com/how-videos-go-viral.html [5] "SPEC Benchmark Results: HP Proliant DL380p Rack Server," http://i.dell.com/sites/doccontent/shared-content/data- sheets/en/Documents/Comparing-Dell-R720-and-HP-Proliant-DL380p-Gen8- Servers.pdf [6] "ETSI NFV Virtualization Requirements," http://www.etsi.org/deliver/etsi_gs/NFV/001_099/004/01.01.01_60/gs_N FV004v010101p.pdf [7] "ETSI NFV Architectural Framework," http://www.etsi.org/deliver/etsi_gs/NFV/001_099/002/01.01.01_60/gs_N FV002v010101p.pdf [8] "OpenStack Open Source Software," https://www.openstack.org/ [9] Fielding, Roy Thomas, "Architectural Styles and the Design of Network-based Software Architectures," Dissertation, University of California, Irvine, 2000 [10] "Hypertext Transfer Protocol - HTTP/1.1," RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235 [11] "ETSI NFV PoC - Virality based content caching in NFV Framework," http://nfvwiki.etsi.org/index.php?title=Virality_based_content_cachi ng_in_NFV_framework Krishnan Expires April 2014 [Page 8] Internet-Draft Open NFV Virality Content Caching September 2013 Authors' Addresses Ram Krishnan Brocade Communications ramk@brocade.com Dilip Krishnaswamy IBM Research dilikris@in.ibm.com Diego Lopez Telefonica I+D Don Ramon de la Cruz, 82 Madrid, 28006, Spain +34 913 129 041 diego.r.lopez@telefonica.com Peter J. Willis BT peter.j.willis@bt.com Asif Qamar Evolv asif@asifqamar.com Krishnan Expires April 2014 [Page 9]