<ICN Research Group> 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.
<Dinh, et al.> Expires December 31, 2018 [Page 1]
Internet-Draft <SDN/NFV in ICN> 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
<Dinh, et al.> Expires December 31, 2018 [Page 2]
Internet-Draft <SDN/NFV in ICN> 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).
<Dinh, et al.> Expires December 31, 2018 [Page 3]
Internet-Draft <SDN/NFV in ICN> 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
<Dinh, et al.> Expires December 31, 2018 [Page 4]
Internet-Draft <SDN/NFV in ICN> 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.
<Dinh, et al.> Expires December 31, 2018 [Page 5]
Internet-Draft <SDN/NFV in ICN> 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
<Dinh, et al.> Expires December 31, 2018 [Page 6]
Internet-Draft <SDN/NFV in ICN> 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.
<Dinh, et al.> Expires December 31, 2018 [Page 7]
Internet-Draft <SDN/NFV in ICN> 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.
<Dinh, et al.> Expires December 31, 2018 [Page 8]
Internet-Draft <SDN/NFV in ICN> 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.
<Dinh, et al.> Expires December 31, 2018 [Page 9]
Internet-Draft <SDN/NFV in ICN> 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.
<Dinh, et al.> Expires December 31, 2018 [Page 10]
Internet-Draft <SDN/NFV in ICN> 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.
<Dinh, et al.> Expires December 31, 2018 [Page 11]
Internet-Draft <SDN/NFV in ICN> 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
<Dinh, et al.> Expires December 31, 2018 [Page 12]
Internet-Draft <SDN/NFV in ICN> July 2, 2018