idnits 2.17.1 draft-krishnan-nfvrg-open-nfv-virality-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 21, 2014) is 3560 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 7235 (ref. '10') (Obsoleted by RFC 9110) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Research Task Force (IRTF) R. Krishnan 2 Internet Draft Brocade 3 Category: Experimental Dilip Krishnaswamy 4 IBM Research 5 D. R. Lopez 6 Telefonica I+D 7 Peter Willis 8 BT 9 Asif Qamar 10 Evolv 12 Expires: December 2014 July 21, 2014 14 An Open NFV Architectural Framework for Virality Based Content 15 Caching 17 draft-krishnan-nfvrg-open-nfv-virality-00 19 Abstract 21 One of the key goals of Network Functions Virtualization (NFV) is 22 achieving energy efficiency through workload consolidation. A good 23 example for maximizing energy savings is the Virtualization of 24 Content Delivery Networks (vCDNs) NFV use case where the video 25 streaming workloads exhibit significant difference between prime- 26 time and non-prime-time usage of the infrastructure. This draft 27 examines the practical challenges in maximizing energy efficiency 28 for vCDN workloads. This draft proposes an open NFV architectural 29 framework for conveying content virality information from Cloud 30 applications such as YouTube, Twitter and mechanisms for leveraging 31 it to maximize the energy efficiency for vCDN workloads. 33 Status of this Memo 35 This Internet-Draft is submitted to IETF in full conformance with 36 the provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF), its areas, and its working groups. Note that 40 other groups may also distribute working documents as Internet- 41 Drafts. 43 Internet-Drafts are draft documents valid for a maximum of six 44 months and may be updated, replaced, or obsoleted by other documents 45 at any time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 The list of current Internet-Drafts can be accessed at 49 http://www.ietf.org/ietf/1id-abstracts.txt. 51 The list of Internet-Draft Shadow Directories can be accessed at 52 http://www.ietf.org/shadow.html. 54 This Internet-Draft will expire on April, 2014. 56 Copyright Notice 58 Copyright (c) 2014 IETF Trust and the persons identified as the 59 document authors. All rights reserved. 61 This document is subject to BCP 78 and the IETF Trust's Legal 62 Provisions Relating to IETF Documents 63 (http://trustee.ietf.org/license-info) in effect on the date of 64 publication of this document. Please review these documents 65 carefully, as they describe your rights and restrictions with 66 respect to this document. 68 Conventions used in this document 70 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 71 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 72 document are to be interpreted as described in RFC 2119. 74 Table of Contents 76 1. Introduction...................................................3 77 2. Open NFV Architectural Framework...............................4 78 3. System Analysis................................................6 79 4. Open API Parameters............................................7 80 4.1. Content Virality Information..............................7 81 4.2. Other Application Information.............................7 82 5. Summary........................................................7 83 6. Future Work....................................................7 84 7. IANA Considerations............................................7 85 8. Security Considerations........................................7 86 9. Acknowledgements...............................................7 87 10. References....................................................7 88 10.1. Normative References.....................................7 89 10.2. Informative References...................................7 90 Authors' Addresses................................................9 92 1. Introduction 94 Network Operators use a variety of proprietary hardware appliances. 95 Hardware appliances, though deliver performance, are complex to 96 manage, not easy to scale up/down in capacity and not cost 97 effective. NFV [1] is a movement by network operators all over the 98 world such as AT&T, BT, CenturyLink, Deutsche Telekom, Telefonica, 99 Verizon, and more to address the aforementioned issues. NFV involves 100 the implementation of network functions in software that can run on 101 a range of industry standard server hardware, and that can be moved 102 to, or instantiated in, various locations in the network as 103 required, without the need for installation of new equipment. NFV 104 has many use cases [2], notable of which is the vCDN. The goal of 105 vCDN would be to address virtualization of all the CDN components, 106 but the biggest and immediate impact would be on the cache nodes 107 given the growth in content especially in mobile networks [3]. 109 The key benefits of vCDN are 111 . Overall capacity is shared by all content delivery appliances 112 and other virtualized appliances. 114 . Since appliances are pure software, it is easy to replace or 115 modify them in the event of new CDN requirements. 117 . Besides caching of operator's own content, this enables 118 operators to offer content caching as a service to CDN 119 providers (e.g. Akamai Aura CDN) and large content providers 120 with private CDNs (e.g. Netflix OpenConnect). 122 Currently, the allocation of VMs for vCDN follows a static model 123 based on weekday prime-time characteristics, business hours etc. 124 This model results in substantial resource over-provisioning, since 125 a lot of content viewed over websites like YouTube and shared over 126 social media like Twitter follow a virality pattern during anytime 127 of weekday or weekend [4]. Additionally, many industry standard 128 servers consume substantial power in the active idle state, which 129 results in severe energy inefficiency. For example, HP ProLiant 130 DL380p Rack Server has a peak power utilization of 324 Watts and 131 consumes 105 Watts (approximately 30% of peak) in the active idle 132 state - this is depicted in Page 17 of [5]. 134 One of the key goals of Network Functions Virtualization (NFV) is 135 achieving energy efficiency through workload consolidation [6]. This 136 draft proposes an open NFV architectural framework for conveying 137 content virality information from applications such as Twitter, 138 Facebook, YouTube and mechanisms for leveraging it to maximize the 139 energy efficiency for vCDN workloads without compromising 140 performance. This enables network operators to offer new types of 141 content caching services to its CDN customers for example, "Virality 142 Based Content Caching" and also optimize the resource usage of their 143 own CDNs. This draft also does a performance comparison of the 144 proposed approach with the current static model of allocation of VMs 145 for vCDNs and demonstrates the benefits of the approach. 147 2. Open NFV Architectural Framework 149 Figure 1 depicts the Open NFV Architectural Framework, adapted from 150 the definition of the ETSI NFV Architectural Framework [7] and 151 extended in this draft to show support for content virality 152 management. It has the following virtual and physical or hardware 153 (HW) infrastructure components as part of NFV Infrastructure (NFVI) 155 1) Compute - physical servers hosting computing elements in the form 156 of Virtual Machines (VMs) 158 2) Storage - physical/virtual storage 160 3) Networking - physical/virtual routers. 162 The Virtual Infrastructure Manager (VIM), which could be 163 accomplished by open source software like OpenStack [8] for example, 164 performs lifecycle management of the above infrastructure components 165 and maintains a dynamic resource pool of the same. Virtual Network 166 Functions (VNFs) such as firewall, load balancer, CDN etc., each of 167 which runs on multiple VMs, are managed by Virtualized Network 168 Function Manager (VNFM), which performs lifecycle management of VNFs 169 and maintains dynamic resource pool(s) for different types of VNFs. 170 The VNFM exchanges Virtual/Physical resource information with the 171 VIM. 173 The other elements of the NFV architectural framework include a 174 service orchestrator, and management and support systems such as an 175 Element Management System (EMS), an Operations Support System (OSS), 176 and a Business Support System (BSS). 178 Content Virality Information 180 -------------------------------------- 182 OPEN API (RESTful etc.)- NFV Boundary 184 -------------------------------------- 186 | | 188 | NFV Architectural Blocks | 190 | (Virtual Network Function | 192 | Manager - VNFM) | 194 -------------------------------------- 196 Figure 1: Open NFV Architectural Framework 198 (Adapted from [7]) 200 The various interfaces in the Open NFV architectural framework are 202 - Vi-Ha - Interface between the virtualization layer (e.g. 203 hypervisor for hardware compute servers) and hardware resources 205 - Vn-Nf - Represents the execution environment provided by the NFVI 206 to VNF (e.g. a single VNF could have multiple VMs) 208 - Nf-Vi - Interface to the VIM - used for VM lifecycle management 209 and other purposes 211 - Ve-Vnfm - Interface between VNF/EMS and VNF Manager - used for 212 VNF lifecycle management and other purposes 214 - Se-Ma - Used for getting information about VNF deployment 215 template and other purposes 217 - Os-Ma - Interface to OSS/BSS - handles network service lifecycle 218 management and other functions. 220 - Vi-Vnfm - Interface between VIM and VNFM - handles resource 221 allocation requests by the VNF manager and other functions 222 - Or-Vnfm - Interface between Orchestrator and VNFM - handles 223 collection of state information necessary for network service 224 lifecycle management and other functions 226 To support content virality information in this open architecture, 227 we suggest the availability of such information through open APIs as 228 depicted in Figure 1. The open API can be based on RESTful framework 229 [9] [10]. Content virality information can be streamed in real-time 230 from applications such as YouTube, and submitted to the VNFM through 231 open APIs. This information can be used by VNFM to populate the 232 dynamic vCDN resource pool with the optimal VNF capacity needed for 233 content caching which can be consolidated to a minimal set of VMs 234 and physical servers. Besides content virality information, we also 235 suggest that the architecture could optionally provide a generic 236 open API framework for handling other application information, such 237 as information regarding firewall services, in real-time if 238 available. 240 In typical current systems, the vCDN resource pool is statically 241 populated by policies such as weekday prime-time characteristics, 242 business hours etc., and can be significantly over-provisioned to 243 handle any dynamic requests. Current systems also do not delve into 244 specific targeted use cases or a framework for conveying application 245 information in real-time. 247 The rest of the contribution of this draft is to develop these 248 aspects further in an open architecture framework as suggested in 249 Figure 1. In effect, the differentiating aspects of the proposed 250 architectural framework in this draft are 252 - A dynamic resource pool that is used to optimally populate the 253 vCDN VNFs with the right amount of VMs and physical servers to 254 minimize over-provisioning. 256 - Parameters of interest for real-time streaming of application 257 information such as content virality, which could be utilized for 258 resource optimization in an open-API framework. 260 3. System Analysis 262 This work is in progress in ETSI NFV as a proof of concept [11]. 263 More details will be described in the upcoming revisions of this 264 draft. 266 4. Open API Parameters 268 4.1. Content Virality Information 270 TBD 272 4.2. Other Application Information 274 TBD 276 5. Summary 278 This draft proposes an NFV architectural framework for conveying 279 content virality information from Cloud applications such as 280 YouTube, Twitter, Facebook and mechanisms for leveraging it to 281 maximize the energy efficiency for vCDN workloads without 282 compromising performance. 284 More - TBD 286 6. Future Work 288 TBD 290 7. IANA Considerations 292 This draft does not have any IANA considerations. 294 8. Security Considerations 296 Security issues may arise due to the usage of open APIs for 297 exchanging content virality information. These security issues apply 298 to all forms of open APIs and not limited to exchange of content 299 virality information. This is an aspect for further detailed study. 301 9. Acknowledgements 303 None. 305 10. References 307 10.1. Normative References 309 10.2. Informative References 311 [1] "ETSI NFV White Paper," 312 http://portal.etsi.org/NFV/NFV_White_Paper.pdf 314 [2] "ETSI NFV Use Cases," 315 http://www.etsi.org/deliver/etsi_gs/NFV/001_099/001/01.01.01_60/gs_N 316 FV001v010101p.pdf 318 [3] "Cisco VNI White Paper: Global Mobile Data Traffic Forecast 319 Update," 320 http://www.cisco.com/en/US/solutions/collateral/ns341/ns525/ns537/ns 321 705/ns827/white_paper_c11-520862.html, February 2014 323 [4] "Facegroup: How Videos go Viral," 324 http://www.facegroup.com/how-videos-go-viral.html 326 [5] "SPEC Benchmark Results: HP Proliant DL380p Rack Server," 327 http://i.dell.com/sites/doccontent/shared-content/data- 328 sheets/en/Documents/Comparing-Dell-R720-and-HP-Proliant-DL380p-Gen8- 329 Servers.pdf 331 [6] "ETSI NFV Virtualization Requirements," 332 http://www.etsi.org/deliver/etsi_gs/NFV/001_099/004/01.01.01_60/gs_N 333 FV004v010101p.pdf 335 [7] "ETSI NFV Architectural Framework," 336 http://www.etsi.org/deliver/etsi_gs/NFV/001_099/002/01.01.01_60/gs_N 337 FV002v010101p.pdf 339 [8] "OpenStack Open Source Software," https://www.openstack.org/ 341 [9] Fielding, Roy Thomas, "Architectural Styles and the Design of 342 Network-based Software Architectures," Dissertation, University of 343 California, Irvine, 2000 345 [10] "Hypertext Transfer Protocol - HTTP/1.1," RFC 7230, RFC 7231, 346 RFC 7232, RFC 7233, RFC 7234, RFC 7235 348 [11] "ETSI NFV PoC - Virality based content caching in NFV 349 Framework," 350 http://nfvwiki.etsi.org/index.php?title=Virality_based_content_cachi 351 ng_in_NFV_framework 353 Authors' Addresses 355 Ram Krishnan 356 Brocade Communications 357 ramk@brocade.com 359 Dilip Krishnaswamy 360 IBM Research 361 dilikris@in.ibm.com 363 Diego Lopez 364 Telefonica I+D 365 Don Ramon de la Cruz, 82 366 Madrid, 28006, Spain 367 +34 913 129 041 368 diego.r.lopez@telefonica.com 370 Peter J. Willis 371 BT 372 peter.j.willis@bt.com 374 Asif Qamar 375 Evolv 376 asif@asifqamar.com