idnits 2.17.1 draft-dinh-icnrg-sdnnfvicn-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: ---------------------------------------------------------------------------- == It seems as if not all pages are separated by form feeds - found 0 form feeds but 12 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 129 instances of too long lines in the document, the longest one being 61 characters in excess of 72. ** There are 134 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 2, 2018) is 2122 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Thanh Dinh 2 Internet Draft Younghan Kim 3 Intended status: Informational Soongsil University, Korea 4 Expires: December 2018 July 2, 2018 6 Considerations for Using SDN/NFV in ICN 7 draft-dinh-icnrg-sdnnfvicn-00.txt 9 Status of this Memo 11 This Internet-Draft is submitted in full conformance with the 12 provisions of BCP 78 and BCP 79. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other documents 21 at any time. It is inappropriate to use Internet-Drafts as 22 reference material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/1id-abstracts.html 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html 30 This Internet-Draft will expire on December 2018. 32 Copyright Notice 34 Copyright (c) 2014 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions 39 Relating to IETF Documents (http://trustee.ietf.org/license-info) 40 in effect on the date of publication of this document. Please 41 review these documents carefully, as they describe your rights 42 and restrictions with respect to this document. 44 Abstract 46 This document provides considerations for using Software-Defined 47 Networking (SDN) / Network Function Virtualization (NFV) in Information-Centric 48 Networking (ICN). 50 Table of Contents 52 1. Introduction..................................................4 53 2. Conventions used in this document.............................5 54 3. NFV benefits for ICN..........................................5 55 3.1. Facilitating ICN deployment.............................5 56 3.2. Reducing CAPEX..........................................5 57 3.3. Facilitating orchestration..............................6 58 4. SDN benefits for ICN..........................................6 59 4.1. Facilitating configuration..............................6 60 4.2. Quick content hierarchy setup...........................6 61 4.3. Cache coordination......................................7 62 5. NFV design considerations for ICN.............................7 63 5.1. IP-based NFVI...........................................7 64 5.2. ICN supported NFVI......................................8 65 5.3. Orchestration...........................................8 66 6. SDN design considerations for ICN.............................9 67 6.1. Application implementation for SDN controller...........9 68 6.2. Application implementation for ICN switches.............9 69 6.3. Name-based packet matching..............................9 70 6.4. Cache coordination......................................9 71 7. Security Considerations.......................................10 72 8. IANA Considerations...........................................10 73 9. Conclusion....................................................10 74 10. Informative References.......................................10 75 1. Introduction 77 Over the last few years, Network Functions Virtualization (NFV) [ETSI-NFV-ARCH] 78 has been becoming one of the most promising study areas for developing new 79 computer network technologies. NFV poses a novel way to develop network services, 80 by using software and virtualization aiming the replacement of proprietary hardware 81 appliances that run network functions. In NFV, these services, called Virtualized 82 Network Functions (VNFs), are implemented through software and deployed in Virtual 83 Machines (VMs), allowing new and efficient ways of network deployment. NFV allows 84 to manage and customize network services according to business needs, enabling 85 tremendous cost savings and more agility to serve the daily changes that networks 86 are susceptible. In addition, network function virtualization (NFV) is undoubtedly 87 one of the key technologies needed to create a smooth path for migration. 89 For network management, Software Defined Networking (SDN) [SDN-Survey] aims to 90 manage the network and the functions provided by separating the control plane 91 from the data plane. The SDN controller(s) possess a global view of the network 92 and can therefore simplify the network management as compared to the traditional 93 distributed architectures typical of the Internet. 95 In ICN, ICN network deployment is challenging. The deployment of a global ICN-based 96 Internet, where an ICN-based protocol takes the networking forwarding role currently 97 occupied by IP, is still a long way [RFC7927]. The interconnection of ICN domains 98 currently involves human intervention to set up IP-encapsulating tunnels, which in 99 the long run implies a tedious and error-prone process that does not scale 101 We envision that leveraging the power and flexibility of SDN/NFV [NFV-Opp] can help 102 in combating the aforementioned ICN deployment problems, thus enabling ICN based 103 services in future networks. SDN/NFV model allows operators to deploy ICN services 104 more quickly and with more flexibility, because specific hardware is not needed with 105 each service and it can all be done with software. 107 This draft describes considerations for using Software-Defined Networking 108 (SDN) / Network Function Virtualization (NFV) in Information-Centric 109 Networking (ICN). 111 2. Conventions used in this document 113 The terms about ICN is defined in [RFC7927]. The terms about VNF, NFV, NFV-MANO 114 are defined in [ETSI-NFV-ARCH]. The terms about SDN is defined in [RFC7927]. 116 3. NFV benefits for ICN 118 3.1. Facilitating ICN deployment 120 Creating a smooth migration path from the current IP network to the ICN is a 121 challenging task that must be investigated. Network function virtualization (NFV) 122 is one of the key technologies to achieve this migration because of its flexibility 123 in supporting new network services as software. 125 Today's network functions are deployed as specific vendor-locked hardware and 126 software components. Since the deployment of new network services always requires 127 a range of new network equipment, it is fairly costly and takes long time to launch 128 the service. 130 In the NFV approach, network functions are separated from specific hardware and 131 run on a virtualized infrastructure called network function virtualization 132 infrastructure (NFVI). NFV also makes it possible to deploy new network protocols 133 and architectures such as ICNs in the virtualized infrastructure. 135 NFV model allows operators to deploy ICN services more quickly and with more 136 flexibility, because specific hardware is not needed with each service - it can 137 all be done with software. 139 3.2 Reducing CAPEX 141 Using NFV helps reduce CAPEX and OPEX for deploying ICN services by enabling 142 commodity servers to host softwarized network functions. Cost is a top consideration 143 for any operator or service provider these days. Using NFV also helps reduce 144 time-to-market to deploy new ICN services 145 3.3. Facilitating orchestration 147 NFV facilitates orchestration for ICN services by exploiting current NFV management 148 and orchestration frameworks, to coordinate the resources and networks needed to set 149 up as well as manage ICN-based services and applications such as service coordination 150 and instantiation, Service chaining, scaling services, Service monitoring and fail 151 recovery/healing. 153 NFV provides a greater flexibility to scale up, scale down or evolve ICN services. 154 To adapt quickly to users' changing needs on content services or provide new content 155 services, operators must be able to scale their network architecture across multiple 156 servers, rather than being limited by what a single box can do. 158 4. SDN benefits for ICN 160 4.1. Facilitating configuration 162 SDN provides a centralized tool to facilitate configuration for ICN nodes, networks, 163 applications, and services. 165 For application level, SDN helps network operators accelerate ICN application deployment 166 and delivery, dramatically reducing costs through policy-enabled work-flow automation. 167 SDN also increases resource flexibility and utilization for ICN applications and 168 reducing costs. 170 For the service level, SDN helps facilitate service function chaining for ICN services. 171 Especially in ICN deployment over IP networks, manual chaining configurations for 172 ICN services may be time consuming and inefficient. 174 4.2. Quick content hierarchy setup 176 The out-of-band configuration with SDN can enable a quick name template and 177 content hierarchy setup, quick distribution of FIB/RIB entries for switches for 178 fast packet forwarding and content distribution in latency-sensitive scenarios 179 like disaster management applications. 181 In conventional method, ICN routing protocols greedily spread routing information 182 and name prefixes through the network, thus incurs high 183 overhead and delay. For example, in disaster scenarios, the commander instantiates 184 a new name template with new name prefixes for setting up new content and recipient 185 hierarchies used for disaster management services in a specific region. If the 186 location of the commander (the disaster management center) is far from the target 187 region, name prefixes may need to be propagated throughout the network by the 188 conventional ICN routing protocol. Therefore, it takes a high delay for the name 189 prefix installation and to be effective at the target region. With SDN, the 190 commander at the disaster management center can easily and quickly install 191 the name prefixes to the network at the target region. 193 In ICN-based Pub/Sub disaster services, instead of waiting for subscribers to 194 subscribe to the publisher or rendezvous point, SDN-based ICN management can 195 enable the commander to setup the network quickly, push advertisement/ invitation 196 to required subscribers (roles involved in a disaster management), then the subscribers 197 just need to accept the invitations. The network and content hierarchy for disaster 198 management thus quickly setup. 200 4.3. Cache coordination 202 In ICN nodes, content caching is one of the key features deciding the performance 203 of ICN. With a global view, SDN can help to optimize cache distribution, cache 204 coordination for efficient cache management and caching-based forwarding. 206 5. NFV design considerations for ICN 208 5.1. IP-based NFVI 210 In current NFVI (IP-based networks), when a host receives a packet, the host's OVS routes 211 it to the VM running the corresponding network function through TAP device and vNIC. 212 Therefore, ICN packets received by NFVI will be forwarded to the corresponding VNFs 213 containing the corresponding ICN functions, i.e., an ICN router. Name Forwarding Daemon (NFD) 214 at VNF-based ICN nodes will process packets. 216 In this case, Tenant domains with ICN protocol stack is decoupled from the NFVI domain 217 in which IP still remains the networking substrate carrying all Internet traffic. 219 Efficient packet encapsulation, decapsulation, and longest prefix matching (LPM) mechanisms 220 are time and overhead consuming while processing in VNF. 222 5.2. ICN supported NFVI 224 NFVI like OVS host provides high performance processing, its capability is sufficient to 225 handle various kinds of packets in exact match manner. Therefore, a level of ICN packet 226 matching can be implemented in NFVI for a fast packet switching. 228 Instead of forwarding ICN packets immediately to corresponding ICN functions (i.e., ICN router) 229 in VMs, if the FIB table entries can be shared with the NFVI or previous matched name prefixes 230 of ICN routers be inserted to OVS flow table, the OVS at NFVI can perform name prefix exact match 231 processing for ICN packets. The NFVI forwards incoming interest packets directly to the next hop 232 if it finds matched entries at OVS [NFVIICN]. This helps reduce overhead and delay in ICN packet 233 processing. IF there is no entry matched, the NFVI forwards the ICN packets to the NFD of ICN 234 nodes running in guest VMs for further process (i.e., longest prefix matching) as normally. 236 5.3. Orchestration 238 Efficient virtual network functions must be designed and implemented. The stateful and CPU intensive 239 nature of an ICN data-plane is hardly compatible with operations on the fly (spawn, migration, etc.). 240 In addition, novel management and orchestration solutions 241 for virtual ICN network stacks must be entirely designed and implemented. 243 In ICN nodes, content caching is one of the key features providing the advantages of ICN. Current cache 244 management and coordination are mostly done by routers. A challenge is that how to efficiently utilize 245 the cache memories across different routers so that the network cache performance of the whole system can 246 be optimized. With NFV, caching management and coordination can be implemented in the orchestrator level 247 for optimization based on global view and offline computation. Caching policy (cache decision, cache 248 replacement, cache capacity scaling, cache resource allocation...) can also be implemented by the orchestrator 249 for efficient caching distribution and coordination for routers. 251 6. SDN design considerations for ICN 253 6.1. Application implementation for SDN controller 255 Applications for ICN management at SDN controller are required. The applications can be responsible for 256 processing data received from ICN switches, matching rules, and computing new routes. 258 6.2. Application implementation for ICN switches 260 Applications for ICN switches/ routers to communicate with the SDN controller are required for i) 261 propagating RIB table (name prefixes, routing info) to controller, ii) when receiving an Interest 262 and has no entry in FIB, the applications should forward the Interest to the 263 controller iii) processing commands from the controller to update local forwarding rules. 265 6.3. Name-based packet matching 267 Current matching in SDN (i.e, OpenFlow) uses pre-defined fields like ingress port, MAC address, 268 source/destination address, source/destination port while ICN interest and data packets are transmitted 269 based on the content name. Therefore, an efficient name-based packet matching scheme is required for SDN. 271 ICN interest and data packets are transmitted based on the content name while SDN (OpenFlow) consists 272 of forwarding IP packets based on IP addresses [SDNICN-Matching]. In additions, content consumers and 273 producers communicate based on name prefixes. One of benefits of SDN for ICN is to facilitate tunneling 274 setups for chaining ICN services between consumers and providers. Efficient mapping between name 275 prefixes and IP addresses, and efficient ICN packet encapsulation and decapsulation with IP packets 276 are in consideration. 278 6.4. Cache coordination 280 For cache coordination, caching distribution rules can be installed and updated by SDN controller for 281 efficient in-network memory space usage. Caching coordination rules can be installed and updated by SDN 282 controller for efficient cache-based routing to reduce routing overhead and improve the network performance. 284 7. Security Considerations 286 TBD. 288 8. IANA Considerations 290 TBD. 292 9. Conclusion 293 This draft offers a comprehensive view of the benefits and considerations of SDN/NFV for ICN. The draft 294 begins by motivating the need for SDN/NFV-ICN by highlighting benefits of SDN/NFV in different ICN scenarios, and 295 then discuss possible research directions from networking and application perspective. 297 10. Informative References 299 [ETSI-NFV-ARCH] 300 Network Function Virtualisation (NFV): architectural 301 Framework 302 [NFV-Opp] 303 B. Han, V. Gopalakrishnan, L. Ji, and S. Lee, "Network function virtualization: Challenges and opportunities for innovations," 304 IEEE Commun. Mag., vol. 53, no. 2, pp. 90-97, Feb. 2015. 305 [SDN-Survey] 306 D. Kreutz, F. M. V. Ramos, P. E. Veranssimo, C. E. Rothenberg, S. Azodolmolky, and S. Uhlig, "Software-defined networking: 307 A comprehensive survey," Proc. of the IEEE, 103(1):14-76, Jan 2015. 308 [RFC7927] 309 D. Kutscher, Ed., S. Eum, K. Pentikousis, I. Psaras, D. Corujo, D. Saucez, T. Schmidt, M. Waehlisch, "Information-Centric 310 Networking (ICN) Research Challenges" IETF RFC 7927, July 2016. 312 [RFC7927] 313 E. Haleplidis, Ed., K. Pentikousis, Ed., S. Denazis, J. Hadi Salim, D. Meyer, and O. Koufopavlou, "Software-Defined Networking 314 (SDN): Layers and Architecture Terminology," IETF RFC 7426, January 2015. 315 [NFVIICN] 316 Kazuaki Ueda, Kenji Yokota, Jun Kurihara, and Atsushi Tagami, "Towards the NFVI-Assisted ICN: Integrating ICN Forwarding into 317 the Virtualization Infrastructure," IEEE Global Communications Conference (GLOBECOM), Washington, DC, USA, 2016. 318 [SDNICN-Matching] 319 P. Zuraniewski, N. van Adrichem, D. Ravesteijn, W. IJntema, C. Papadopoulos, C. Fan, "Facilitating icn deployment with an 320 extended openflow protocol", Proceedings of the 4th ACM Conference on Information-Centric Networking, 2017. 322 Authors' Addresses 324 Thanh Dinh 325 Soongsil University 326 4F Hyungnam Engineering Bldg. 424, 327 (156-743) 511 Sangdo-Dong, Dongjak-Gu, Seoul, Korea 329 Phone: +82 10 3284 8442 330 Email: thanhdcn@dcn.ssu.ac.kr 332 Younghan Kim 333 Soongsil University 334 4F Hyungnam Engineering Bldg. 424, 335 (156-743) 511 Sangdo-Dong, Dongjak-Gu, Seoul, Korea 337 Phone: +82-2-820-0904 338 Email: younghak@ssu.ac.kr