[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

ICN Research Group                                               E. Paik
Internet-Draft                                                    W. Yun
Expires: January 14, 2014                                             KT
                                                                 T. Kwon
                                                                 H. Choi
                                                           July 13, 2013

      Deployment Considerations for Information-Centric Networking


   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

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

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in [RFC2119].

   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

   - 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

   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

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

Authors' Addresses

   EunKyoung Paik
   Infra R&D Lab. KT
   17 Woomyeon-dong, Seocho-gu
   Seoul  137-792

   Phone: +82-2-526-5233
   Fax:   +82-2-526-5200
   Email: eun.paik@kt.com
   URI:   http://mmlab.snu.ac.kr/~eun/

   Won-Dong Yun
   Infra R&D Lab. KT
   17 Woomyeon-dong, Seocho-gu
   Seoul  137-792

   Phone: +82-2-526-6688
   Fax:   +82-2-526-5200
   Email: wd.yun@kt.com

   Taekyoung Kwon
   Seoul National University
   Multimedia Communications Lab., Seoul National Univ.
   1 Gwanak-ro, Kwanak-gu
   Seoul  151-744

   Phone: +82-2-880-9105
   Fax:   +82-2-872-2045
   Email: tkkwon@snu.ac.kr
   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

   Phone: +82-2-880-1832
   Fax:   +82-2-872-2045
   Email: hgchoi@mmlab.snu.ac.kr
   URI:   http://mmlab.snu.ac.kr/~hgchoi/

Paik, et al.            Expires January 14, 2014                [Page 7]

Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/