Deployment Considerations for Information-Centric Networking
Author(s): Taekyoung Kwon, email@example.com, Won-Dong Yun, EunKyoung Paik
The objective of ICN RG is to produce documents such as a survey of diverse approaches, problem statement, and reference scenario. This document provides deployment issues of ICN considering its migration techniques and coexistance environement with legacy network...
ICN Research Group E. Paik Internet-Draft W. Yun Expires: January 14, 2014 KT T. Kwon H. Choi SNU July 13, 2013 Deployment Considerations for Information-Centric Networking draft-paik-icn-deployment-considerations-00.txt Abstract The objective of ICN RG is to produce documents such as a survey of diverse approaches, problem statement, and reference scenario. This document provides deployment issues of ICN considering its migration techniques and coexistance environement with legacy network technologies. 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). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on January 14, 2014. Copyright Notice Copyright (c) 2013 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. Code Components extracted from this document must Paik, et al. Expires January 14, 2014 [Page 1] Internet-Draft sdiff-benefits July 2013 include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 3. ICN Deployment Considerations . . . . . . . . . . . . . . . . 3 3.1. Overlay Approach . . . . . . . . . . . . . . . . . . . . 3 3.2. Interconnection Approach . . . . . . . . . . . . . . . . 3 3.3. Dual Stack Approach . . . . . . . . . . . . . . . . . . . 4 3.4. Isolation Approach . . . . . . . . . . . . . . . . . . . 5 4. Use Cases for Deployment . . . . . . . . . . . . . . . . . . 5 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 6. Normative References . . . . . . . . . . . . . . . . . . . . 5 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction As mobile multimedia streaming and cloud services are becoming pervasice, technilogies such as CDN (Content Delivery Networking) and /or P2P provides traffic optimization using caching, content-routing, and so on. While CDN and P2P provides application layer solution, ICN supports network infrastructure evolution with named data that is independant from location. This document provides deployment issues of ICN considering its migration techniques and coexistance environement with legacy network technologies. 2. Terminology 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]. The following terms are defined: - Information-Centric Networking: ICN (Information-Centric Networking) is an approach to evolve the Internet infrastructure introducing uniquely named data as a core Internet principle. - Software-Defined Networking: SDN (Software-Defined Networking) provides network programmability by separating control plane and data plane of network infrastructure. Paik, et al. Expires January 14, 2014 [Page 2] Internet-Draft sdiff-benefits July 2013 3. ICN Deployment Considerations ICN can be deployed either by evolutionary approaches or revolutionary ones. - Evolutionay Deployment: Evolutionay deployment approach includes overlay, interconnection, and dual stack. This approache supports step-by-step deployment and soft migration of ICN. - Revolutionay Deployment: Revolutionay deployment approach demands for redesign of network layer. In contrast, revolutionay deployment can be implemented in an isolation manner. Following sections describe above approaches. 3.1. Overlay Approach Information-Centric "overaly" network can be implemented by tunneling. By using tunneling, ICN payload can be carried over legacy network. For example, ICN protocol can operates as a higher layer running over network layer. Overlaid ICN is beneficial since it is easy to deploy. It does not demand for replacement of legacy network equipments. 3.2. Interconnection Approach ICN and legacy network could be coexisted by translation gateway. Translation gateway approach provides a simple and compelling solution to be coexisted with legacy network like Network Adress Traslation technology. Traditionally, NAT are used to connect an isolated address realm with private unregisted addresses to an external realm with globally unique registered addresses. A network's internal IP addresses cannot be used outside the network either because they are invalid for use outside. Translation is similar to NATs, in that, isolated clouds exist and a gateway connect each cloud, ICN and legacy network, with converting packets. As requested contents are not in ICN cloud, gateway located at the edge of ICN or legacy network translates messages with the appropriate formats for each network. When a gateway received an interest packet, the gateway translates it with http message format to be used for contents service. The following example procedure shows a translation approach of interworking between ICN and legacy network. Paik, et al. Expires January 14, 2014 [Page 3] Internet-Draft sdiff-benefits July 2013 First, ICN sends an interest packet to request a content. If a reqested content exists within ICN cloud, the content could be searched with normal ICN search process, but if the contents are not in ICN cloud, the interest packet could be delivered to a gateway. Second, when the gateway received the interest packet, content ID is extracted in the gateway. Then the gateway convertes the interest packet into a packet with a http message format including content ID and URL mapping information prefetched from internet servers. Third, the gateway sends the converted packet with http message type to a content server. Fourth, When the content server receives the http-typed packet, it delivers the contents the gateway. Fifth, the gateway converts the received data packet into ICN data packet, and sends the data packet to ICN. Then the ICN data packet could be delivered into a requester who want the content with a normal ICN delivery mechanism. ICN cloud -------------------------------------- V | Interest message type V | ^ V +---------+ ^ V | GateWay | ^ V | Device | ^ V +---------+ ^ V | ^ http message type | ^ -------------------------------------- legacy network cloud Figure 1: Internal process of Translator Translation manner described in this document has several ramification. - Overhead: The issue of translation approach is overhead when a message is converted-extraction and reorganization. - Ease of Implementation: Translation approach can be simply implemented and use tons of application, security, load balancing, and so on. 3.3. Dual Stack Approach Paik, et al. Expires January 14, 2014 [Page 4] Internet-Draft sdiff-benefits July 2013 ICN and legacy IP network could coexist by a dual stack approach. A dual stack node refers to a network node (like a router) that can handle both IP and ICN packets. The IP packet and ICN one may not have completely different formats. While the format of an ICN packet is not yet standardized, we assume there can be three options for a dual stack node to see the content names of an ICN packet. First, a dual stack node can see a content name (e.g., HTTP URI) in the payload of an IP packet by deep packet inspection (DPI). Second, an end-node can attach a content name in the IP option header. Third, there are truly two incompatible packet types: IP packet and ICN packet. Depending on the selected option, the design and implementation overhead of a dual stack node will be different. On receipt of an ICN packet, a dual stack node can either tunnel the packet to the next overlay node (over an IP network), or forward the packet the next hop node (i.e., an ICN node or dual stack node). 3.4. Isolation Approach ICN could be deployed revolutionay by isolating ICNs from legacy networks. The isolation approached can be implemented either vertically or horizontally. Firstly, pure ICN can be deployed for specific services that could exist as an island network, e.g., mobile ad-hoc networks. Secondly, pure ICN can be deployed by isolating it horizontally with network slicing. For exanple, software-Defined Networking (SDN) can support the isolation of ICN from legacy networks. 4. Use Cases for Deployment ICN migration issues described in section 3 considers technical alternatives for deployment. In the real world, ICN can be deployed with specific use cases, e.g., home networks, vehicular networks, and so on. ICN use cases impact on the deployment of ICN. 5. Security Considerations We do not consider any security issues in this draft. 6. Normative References Paik, et al. Expires January 14, 2014 [Page 5] Internet-Draft sdiff-benefits July 2013 [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Authors' Addresses EunKyoung Paik KT Infra R&D Lab. KT 17 Woomyeon-dong, Seocho-gu Seoul 137-792 Korea Phone: +82-2-526-5233 Fax: +82-2-526-5200 Email: firstname.lastname@example.org URI: http://mmlab.snu.ac.kr/~eun/ Won-Dong Yun KT Infra R&D Lab. KT 17 Woomyeon-dong, Seocho-gu Seoul 137-792 Korea Phone: +82-2-526-6688 Fax: +82-2-526-5200 Email: email@example.com Taekyoung Kwon Seoul National University Multimedia Communications Lab., Seoul National Univ. 1 Gwanak-ro, Kwanak-gu Seoul 151-744 Korea Phone: +82-2-880-9105 Fax: +82-2-872-2045 Email: firstname.lastname@example.org URI: http://mmlab.snu.ac.kr/~tk/ Paik, et al. Expires January 14, 2014 [Page 6] Internet-Draft sdiff-benefits July 2013 Hoon-gyu Choi Seoul National University Multimedia Communications Lab., Seoul National Univ. 1 Gwanak-ro, Kwanak-gu Seoul 151-744 Korea Phone: +82-2-880-1832 Fax: +82-2-872-2045 Email: email@example.com URI: http://mmlab.snu.ac.kr/~hgchoi/ Paik, et al. Expires January 14, 2014 [Page 7]