Thanh Dinh Internet Draft Younghan Kim Intended status: Informational Soongsil University, Korea Expires: December 2018 July 2, 2018 Considerations for Using SDN/NFV in ICN draft-dinh-icnrg-sdnnfvicn-00.txt Status of this Memo This Internet-Draft is submitted 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 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/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on December 2018. 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. Expires December 31, 2018 [Page 1] Internet-Draft July 2, 2018 Abstract This document provides considerations for using Software-Defined Networking (SDN) / Network Function Virtualization (NFV) in Information-Centric Networking (ICN). Table of Contents 1. Introduction..................................................4 2. Conventions used in this document.............................5 3. NFV benefits for ICN..........................................5 3.1. Facilitating ICN deployment.............................5 3.2. Reducing CAPEX..........................................5 3.3. Facilitating orchestration..............................6 4. SDN benefits for ICN..........................................6 4.1. Facilitating configuration..............................6 4.2. Quick content hierarchy setup...........................6 4.3. Cache coordination......................................7 5. NFV design considerations for ICN.............................7 5.1. IP-based NFVI...........................................7 5.2. ICN supported NFVI......................................8 5.3. Orchestration...........................................8 6. SDN design considerations for ICN.............................9 6.1. Application implementation for SDN controller...........9 6.2. Application implementation for ICN switches.............9 6.3. Name-based packet matching..............................9 6.4. Cache coordination......................................9 7. Security Considerations.......................................10 8. IANA Considerations...........................................10 9. Conclusion....................................................10 10. Informative References.......................................10 Expires December 31, 2018 [Page 2] Internet-Draft July 2, 2018 1. Introduction Over the last few years, Network Functions Virtualization (NFV) [ETSI-NFV-ARCH] has been becoming one of the most promising study areas for developing new computer network technologies. NFV poses a novel way to develop network services, by using software and virtualization aiming the replacement of proprietary hardware appliances that run network functions. In NFV, these services, called Virtualized Network Functions (VNFs), are implemented through software and deployed in Virtual Machines (VMs), allowing new and efficient ways of network deployment. NFV allows to manage and customize network services according to business needs, enabling tremendous cost savings and more agility to serve the daily changes that networks are susceptible. In addition, network function virtualization (NFV) is undoubtedly one of the key technologies needed to create a smooth path for migration. For network management, Software Defined Networking (SDN) [SDN-Survey] aims to manage the network and the functions provided by separating the control plane from the data plane. The SDN controller(s) possess a global view of the network and can therefore simplify the network management as compared to the traditional distributed architectures typical of the Internet. In ICN, ICN network deployment is challenging. The deployment of a global ICN-based Internet, where an ICN-based protocol takes the networking forwarding role currently occupied by IP, is still a long way [RFC7927]. The interconnection of ICN domains currently involves human intervention to set up IP-encapsulating tunnels, which in the long run implies a tedious and error-prone process that does not scale We envision that leveraging the power and flexibility of SDN/NFV [NFV-Opp] can help in combating the aforementioned ICN deployment problems, thus enabling ICN based services in future networks. SDN/NFV model allows operators to deploy ICN services more quickly and with more flexibility, because specific hardware is not needed with each service and it can all be done with software. This draft describes considerations for using Software-Defined Networking (SDN) / Network Function Virtualization (NFV) in Information-Centric Networking (ICN). Expires December 31, 2018 [Page 3] Internet-Draft July 2, 2018 2. Conventions used in this document The terms about ICN is defined in [RFC7927]. The terms about VNF, NFV, NFV-MANO are defined in [ETSI-NFV-ARCH]. The terms about SDN is defined in [RFC7927]. 3. NFV benefits for ICN 3.1. Facilitating ICN deployment Creating a smooth migration path from the current IP network to the ICN is a challenging task that must be investigated. Network function virtualization (NFV) is one of the key technologies to achieve this migration because of its flexibility in supporting new network services as software. Today's network functions are deployed as specific vendor-locked hardware and software components. Since the deployment of new network services always requires a range of new network equipment, it is fairly costly and takes long time to launch the service. In the NFV approach, network functions are separated from specific hardware and run on a virtualized infrastructure called network function virtualization infrastructure (NFVI). NFV also makes it possible to deploy new network protocols and architectures such as ICNs in the virtualized infrastructure. NFV model allows operators to deploy ICN services more quickly and with more flexibility, because specific hardware is not needed with each service - it can all be done with software. 3.2 Reducing CAPEX Using NFV helps reduce CAPEX and OPEX for deploying ICN services by enabling commodity servers to host softwarized network functions. Cost is a top consideration for any operator or service provider these days. Using NFV also helps reduce time-to-market to deploy new ICN services Expires December 31, 2018 [Page 4] Internet-Draft July 2, 2018 3.3. Facilitating orchestration NFV facilitates orchestration for ICN services by exploiting current NFV management and orchestration frameworks, to coordinate the resources and networks needed to set up as well as manage ICN-based services and applications such as service coordination and instantiation, Service chaining, scaling services, Service monitoring and fail recovery/healing. NFV provides a greater flexibility to scale up, scale down or evolve ICN services. To adapt quickly to users' changing needs on content services or provide new content services, operators must be able to scale their network architecture across multiple servers, rather than being limited by what a single box can do. Expires December 31, 2018 [Page 5] Internet-Draft July 2, 2018 4. SDN benefits for ICN 4.1. Facilitating configuration SDN provides a centralized tool to facilitate configuration for ICN nodes, networks, applications, and services. For application level, SDN helps network operators accelerate ICN application deployment and delivery, dramatically reducing costs through policy-enabled work-flow automation. SDN also increases resource flexibility and utilization for ICN applications and reducing costs. For the service level, SDN helps facilitate service function chaining for ICN services. Especially in ICN deployment over IP networks, manual chaining configurations for ICN services may be time consuming and inefficient. 4.2. Quick content hierarchy setup The out-of-band configuration with SDN can enable a quick name template and content hierarchy setup, quick distribution of FIB/RIB entries for switches for fast packet forwarding and content distribution in latency-sensitive scenarios like disaster management applications. In conventional method, ICN routing protocols greedily spread routing information and name prefixes through the network, thus incurs high Expires December 31, 2018 [Page 6] Internet-Draft July 2, 2018 overhead and delay. For example, in disaster scenarios, the commander instantiates a new name template with new name prefixes for setting up new content and recipient hierarchies used for disaster management services in a specific region. If the location of the commander (the disaster management center) is far from the target region, name prefixes may need to be propagated throughout the network by the conventional ICN routing protocol. Therefore, it takes a high delay for the name prefix installation and to be effective at the target region. With SDN, the commander at the disaster management center can easily and quickly install the name prefixes to the network at the target region. In ICN-based Pub/Sub disaster services, instead of waiting for subscribers to subscribe to the publisher or rendezvous point, SDN-based ICN management can enable the commander to setup the network quickly, push advertisement/ invitation to required subscribers (roles involved in a disaster management), then the subscribers just need to accept the invitations. The network and content hierarchy for disaster management thus quickly setup. 4.3. Cache coordination In ICN nodes, content caching is one of the key features deciding the performance of ICN. With a global view, SDN can help to optimize cache distribution, cache coordination for efficient cache management and caching-based forwarding. 5. NFV design considerations for ICN 5.1. IP-based NFVI In current NFVI (IP-based networks), when a host receives a packet, the host's OVS routes it to the VM running the corresponding network function through TAP device and vNIC. Therefore, ICN packets received by NFVI will be forwarded to the corresponding VNFs containing the corresponding ICN functions, i.e., an ICN router. Name Forwarding Daemon (NFD) at VNF-based ICN nodes will process packets. In this case, Tenant domains with ICN protocol stack is decoupled from the NFVI domain in which IP still remains the networking substrate carrying all Internet traffic. Efficient packet encapsulation, decapsulation, and longest prefix matching (LPM) mechanisms are time and overhead consuming while processing in VNF. Expires December 31, 2018 [Page 7] Internet-Draft July 2, 2018 5.2. ICN supported NFVI NFVI like OVS host provides high performance processing, its capability is sufficient to handle various kinds of packets in exact match manner. Therefore, a level of ICN packet matching can be implemented in NFVI for a fast packet switching. Instead of forwarding ICN packets immediately to corresponding ICN functions (i.e., ICN router) in VMs, if the FIB table entries can be shared with the NFVI or previous matched name prefixes of ICN routers be inserted to OVS flow table, the OVS at NFVI can perform name prefix exact match processing for ICN packets. The NFVI forwards incoming interest packets directly to the next hop if it finds matched entries at OVS [NFVIICN]. This helps reduce overhead and delay in ICN packet processing. IF there is no entry matched, the NFVI forwards the ICN packets to the NFD of ICN nodes running in guest VMs for further process (i.e., longest prefix matching) as normally. 5.3. Orchestration Efficient virtual network functions must be designed and implemented. The stateful and CPU intensive nature of an ICN data-plane is hardly compatible with operations on the fly (spawn, migration, etc.). In addition, novel management and orchestration solutions for virtual ICN network stacks must be entirely designed and implemented. In ICN nodes, content caching is one of the key features providing the advantages of ICN. Current cache management and coordination are mostly done by routers. A challenge is that how to efficiently utilize the cache memories across different routers so that the network cache performance of the whole system can be optimized. With NFV, caching management and coordination can be implemented in the orchestrator level for optimization based on global view and offline computation. Caching policy (cache decision, cache replacement, cache capacity scaling, cache resource allocation...) can also be implemented by the orchestrator for efficient caching distribution and coordination for routers. Expires December 31, 2018 [Page 8] Internet-Draft July 2, 2018 6. SDN design considerations for ICN 6.1. Application implementation for SDN controller Applications for ICN management at SDN controller are required. The applications can be responsible for processing data received from ICN switches, matching rules, and computing new routes. 6.2. Application implementation for ICN switches Applications for ICN switches/ routers to communicate with the SDN controller are required for i) propagating RIB table (name prefixes, routing info) to controller, ii) when receiving an Interest and has no entry in FIB, the applications should forward the Interest to the controller iii) processing commands from the controller to update local forwarding rules. 6.3. Name-based packet matching Current matching in SDN (i.e, OpenFlow) uses pre-defined fields like ingress port, MAC address, source/destination address, source/destination port while ICN interest and data packets are transmitted based on the content name. Therefore, an efficient name-based packet matching scheme is required for SDN. ICN interest and data packets are transmitted based on the content name while SDN (OpenFlow) consists of forwarding IP packets based on IP addresses [SDNICN-Matching]. In additions, content consumers and producers communicate based on name prefixes. One of benefits of SDN for ICN is to facilitate tunneling setups for chaining ICN services between consumers and providers. Efficient mapping between name prefixes and IP addresses, and efficient ICN packet encapsulation and decapsulation with IP packets are in consideration. 6.4. Cache coordination For cache coordination, caching distribution rules can be installed and updated by SDN controller for efficient in-network memory space usage. Caching coordination rules can be installed and updated by SDN controller for efficient cache-based routing to reduce routing overhead and improve the network performance. Expires December 31, 2018 [Page 9] Internet-Draft July 2, 2018 7. Security Considerations TBD. 8. IANA Considerations TBD. 9. Conclusion This draft offers a comprehensive view of the benefits and considerations of SDN/NFV for ICN. The draft begins by motivating the need for SDN/NFV-ICN by highlighting benefits of SDN/NFV in different ICN scenarios, and then discuss possible research directions from networking and application perspective. 10. Informative References [ETSI-NFV-ARCH] Network Function Virtualisation (NFV): architectural Framework [NFV-Opp] B. Han, V. Gopalakrishnan, L. Ji, and S. Lee, "Network function virtualization: Challenges and opportunities for innovations," IEEE Commun. Mag., vol. 53, no. 2, pp. 90-97, Feb. 2015. [SDN-Survey] D. Kreutz, F. M. V. Ramos, P. E. Veranssimo, C. E. Rothenberg, S. Azodolmolky, and S. Uhlig, "Software-defined networking: A comprehensive survey," Proc. of the IEEE, 103(1):14-76, Jan 2015. [RFC7927] D. Kutscher, Ed., S. Eum, K. Pentikousis, I. Psaras, D. Corujo, D. Saucez, T. Schmidt, M. Waehlisch, "Information-Centric Networking (ICN) Research Challenges" IETF RFC 7927, July 2016. Expires December 31, 2018 [Page 10] Internet-Draft July 2, 2018 [RFC7927] E. Haleplidis, Ed., K. Pentikousis, Ed., S. Denazis, J. Hadi Salim, D. Meyer, and O. Koufopavlou, "Software-Defined Networking (SDN): Layers and Architecture Terminology," IETF RFC 7426, January 2015. [NFVIICN] Kazuaki Ueda, Kenji Yokota, Jun Kurihara, and Atsushi Tagami, "Towards the NFVI-Assisted ICN: Integrating ICN Forwarding into the Virtualization Infrastructure," IEEE Global Communications Conference (GLOBECOM), Washington, DC, USA, 2016. [SDNICN-Matching] P. Zuraniewski, N. van Adrichem, D. Ravesteijn, W. IJntema, C. Papadopoulos, C. Fan, "Facilitating icn deployment with an extended openflow protocol", Proceedings of the 4th ACM Conference on Information-Centric Networking, 2017. Expires December 31, 2018 [Page 11] Internet-Draft July 2, 2018 Authors' Addresses Thanh Dinh Soongsil University 4F Hyungnam Engineering Bldg. 424, (156-743) 511 Sangdo-Dong, Dongjak-Gu, Seoul, Korea Phone: +82 10 3284 8442 Email: thanhdcn@dcn.ssu.ac.kr Younghan Kim Soongsil University 4F Hyungnam Engineering Bldg. 424, (156-743) 511 Sangdo-Dong, Dongjak-Gu, Seoul, Korea Phone: +82-2-820-0904 Email: younghak@ssu.ac.kr Expires December 31, 2018 [Page 12] Internet-Draft July 2, 2018