Internet DRAFT - draft-paik-icn-deployment-considerations
draft-paik-icn-deployment-considerations
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 [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
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
[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]
