Movatterモバイル変換


[0]ホーム

URL:



ICN Research Group                                               E. PaikInternet-Draft                                                    W. YunExpires: January 14, 2014                                             KT                                                                 T. Kwon                                                                 H. Choi                                                                     SNU                                                           July 13, 2013Deployment Considerations for Information-Centric Networkingdraft-paik-icn-deployment-considerations-00.txtAbstract   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 ofBCP 78 andBCP 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 athttp://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 toBCP 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 mustPaik, 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 Contents1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .22.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .23.  ICN Deployment Considerations . . . . . . . . . . . . . . . .33.1.  Overlay Approach  . . . . . . . . . . . . . . . . . . . .33.2.  Interconnection Approach  . . . . . . . . . . . . . . . .33.3.  Dual Stack Approach . . . . . . . . . . . . . . . . . . .43.4.  Isolation Approach  . . . . . . . . . . . . . . . . . . .54.  Use Cases for Deployment  . . . . . . . . . . . . . . . . . .55.  Security Considerations . . . . . . . . . . . . . . . . . . .56.  Normative References  . . . . . . . . . . . . . . . . . . . .5   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .61.  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 [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 20133.  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 ApproachPaik, 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 insection 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 ReferencesPaik, 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   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: eun.paik@kt.com   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: wd.yun@kt.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: 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   Korea   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]
Datatracker

draft-paik-icn-deployment-considerations-00
Expired Internet-Draft (individual)

DocumentDocument typeExpired Internet-Draft (individual)
Expired & archived
This document is an Internet-Draft (I-D). Anyone may submit an I-D to the IETF. This I-D isnot endorsed by the IETF and hasno formal standing in theIETF standards process.
Select version
AuthorsEunKyoung Paik,Won-Dong Yun,Taekyoung Kwon,hgchoi@mmlab.snu.ac.kr
Email authors
RFC stream (None)
Intended RFC status (None)
Other formats
Report a datatracker bug

[8]ページ先頭

©2009-2025 Movatter.jp