idnits 2.17.1 draft-paik-icn-deployment-considerations-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 13, 2013) is 3940 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ICN Research Group E. Paik 3 Internet-Draft W. Yun 4 Expires: January 14, 2014 KT 5 T. Kwon 6 H. Choi 7 SNU 8 July 13, 2013 10 Deployment Considerations for Information-Centric Networking 11 draft-paik-icn-deployment-considerations-00.txt 13 Abstract 15 The objective of ICN RG is to produce documents such as a survey of 16 diverse approaches, problem statement, and reference scenario. This 17 document provides deployment issues of ICN considering its migration 18 techniques and coexistance environement with legacy network 19 technologies. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on January 14, 2014. 38 Copyright Notice 40 Copyright (c) 2013 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 57 3. ICN Deployment Considerations . . . . . . . . . . . . . . . . 3 58 3.1. Overlay Approach . . . . . . . . . . . . . . . . . . . . 3 59 3.2. Interconnection Approach . . . . . . . . . . . . . . . . 3 60 3.3. Dual Stack Approach . . . . . . . . . . . . . . . . . . . 4 61 3.4. Isolation Approach . . . . . . . . . . . . . . . . . . . 5 62 4. Use Cases for Deployment . . . . . . . . . . . . . . . . . . 5 63 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 64 6. Normative References . . . . . . . . . . . . . . . . . . . . 5 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 67 1. Introduction 69 As mobile multimedia streaming and cloud services are becoming 70 pervasice, technilogies such as CDN (Content Delivery Networking) and 71 /or P2P provides traffic optimization using caching, content-routing, 72 and so on. While CDN and P2P provides application layer solution, 73 ICN supports network infrastructure evolution with named data that is 74 independant from location. 76 This document provides deployment issues of ICN considering its 77 migration techniques and coexistance environement with legacy network 78 technologies. 80 2. Terminology 82 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 83 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 84 document are to be interpreted as described in [RFC2119]. 86 The following terms are defined: 88 - Information-Centric Networking: ICN (Information-Centric 89 Networking) is an approach to evolve the Internet infrastructure 90 introducing uniquely named data as a core Internet principle. 92 - Software-Defined Networking: SDN (Software-Defined Networking) 93 provides network programmability by separating control plane and 94 data plane of network infrastructure. 96 3. ICN Deployment Considerations 98 ICN can be deployed either by evolutionary approaches or 99 revolutionary ones. 101 - Evolutionay Deployment: Evolutionay deployment approach includes 102 overlay, interconnection, and dual stack. This approache supports 103 step-by-step deployment and soft migration of ICN. 105 - Revolutionay Deployment: Revolutionay deployment approach demands 106 for redesign of network layer. In contrast, revolutionay 107 deployment can be implemented in an isolation manner. 109 Following sections describe above approaches. 111 3.1. Overlay Approach 113 Information-Centric "overaly" network can be implemented by 114 tunneling. By using tunneling, ICN payload can be carried over 115 legacy network. For example, ICN protocol can operates as a higher 116 layer running over network layer. 118 Overlaid ICN is beneficial since it is easy to deploy. It does not 119 demand for replacement of legacy network equipments. 121 3.2. Interconnection Approach 123 ICN and legacy network could be coexisted by translation gateway. 124 Translation gateway approach provides a simple and compelling 125 solution to be coexisted with legacy network like Network Adress 126 Traslation technology. Traditionally, NAT are used to connect an 127 isolated address realm with private unregisted addresses to an 128 external realm with globally unique registered addresses. A 129 network's internal IP addresses cannot be used outside the network 130 either because they are invalid for use outside. 132 Translation is similar to NATs, in that, isolated clouds exist and a 133 gateway connect each cloud, ICN and legacy network, with converting 134 packets. As requested contents are not in ICN cloud, gateway located 135 at the edge of ICN or legacy network translates messages with the 136 appropriate formats for each network. When a gateway received an 137 interest packet, the gateway translates it with http message format 138 to be used for contents service. 140 The following example procedure shows a translation approach of 141 interworking between ICN and legacy network. 143 First, ICN sends an interest packet to request a content. If a 144 reqested content exists within ICN cloud, the content could be 145 searched with normal ICN search process, but if the contents are not 146 in ICN cloud, the interest packet could be delivered to a gateway. 148 Second, when the gateway received the interest packet, content ID is 149 extracted in the gateway. Then the gateway convertes the interest 150 packet into a packet with a http message format including content ID 151 and URL mapping information prefetched from internet servers. 153 Third, the gateway sends the converted packet with http message type 154 to a content server. 156 Fourth, When the content server receives the http-typed packet, it 157 delivers the contents the gateway. 159 Fifth, the gateway converts the received data packet into ICN data 160 packet, and sends the data packet to ICN. Then the ICN data packet 161 could be delivered into a requester who want the content with a 162 normal ICN delivery mechanism. 164 ICN cloud 165 -------------------------------------- 166 V | Interest message type 167 V | ^ 168 V +---------+ ^ 169 V | GateWay | ^ 170 V | Device | ^ 171 V +---------+ ^ 172 V | ^ 173 http message type | ^ 174 -------------------------------------- 175 legacy network cloud 177 Figure 1: Internal process of Translator 179 Translation manner described in this document has several 180 ramification. 182 - Overhead: The issue of translation approach is overhead when a 183 message is converted-extraction and reorganization. 185 - Ease of Implementation: Translation approach can be simply 186 implemented and use tons of application, security, load balancing, 187 and so on. 189 3.3. Dual Stack Approach 190 ICN and legacy IP network could coexist by a dual stack approach. A 191 dual stack node refers to a network node (like a router) that can 192 handle both IP and ICN packets. The IP packet and ICN one may not 193 have completely different formats. While the format of an ICN packet 194 is not yet standardized, we assume there can be three options for a 195 dual stack node to see the content names of an ICN packet. 197 First, a dual stack node can see a content name (e.g., HTTP URI) in 198 the payload of an IP packet by deep packet inspection (DPI). 200 Second, an end-node can attach a content name in the IP option 201 header. 203 Third, there are truly two incompatible packet types: IP packet and 204 ICN packet. 206 Depending on the selected option, the design and implementation 207 overhead of a dual stack node will be different. On receipt of an 208 ICN packet, a dual stack node can either tunnel the packet to the 209 next overlay node (over an IP network), or forward the packet the 210 next hop node (i.e., an ICN node or dual stack node). 212 3.4. Isolation Approach 214 ICN could be deployed revolutionay by isolating ICNs from legacy 215 networks. The isolation approached can be implemented either 216 vertically or horizontally. 218 Firstly, pure ICN can be deployed for specific services that could 219 exist as an island network, e.g., mobile ad-hoc networks. 221 Secondly, pure ICN can be deployed by isolating it horizontally with 222 network slicing. For exanple, software-Defined Networking (SDN) can 223 support the isolation of ICN from legacy networks. 225 4. Use Cases for Deployment 227 ICN migration issues described in section 3 considers technical 228 alternatives for deployment. In the real world, ICN can be deployed 229 with specific use cases, e.g., home networks, vehicular networks, and 230 so on. ICN use cases impact on the deployment of ICN. 232 5. Security Considerations 234 We do not consider any security issues in this draft. 236 6. Normative References 238 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 239 Requirement Levels", BCP 14, RFC 2119, March 1997. 241 Authors' Addresses 243 EunKyoung Paik 244 KT 245 Infra R&D Lab. KT 246 17 Woomyeon-dong, Seocho-gu 247 Seoul 137-792 248 Korea 250 Phone: +82-2-526-5233 251 Fax: +82-2-526-5200 252 Email: eun.paik@kt.com 253 URI: http://mmlab.snu.ac.kr/~eun/ 255 Won-Dong Yun 256 KT 257 Infra R&D Lab. KT 258 17 Woomyeon-dong, Seocho-gu 259 Seoul 137-792 260 Korea 262 Phone: +82-2-526-6688 263 Fax: +82-2-526-5200 264 Email: wd.yun@kt.com 266 Taekyoung Kwon 267 Seoul National University 268 Multimedia Communications Lab., Seoul National Univ. 269 1 Gwanak-ro, Kwanak-gu 270 Seoul 151-744 271 Korea 273 Phone: +82-2-880-9105 274 Fax: +82-2-872-2045 275 Email: tkkwon@snu.ac.kr 276 URI: http://mmlab.snu.ac.kr/~tk/ 277 Hoon-gyu Choi 278 Seoul National University 279 Multimedia Communications Lab., Seoul National Univ. 280 1 Gwanak-ro, Kwanak-gu 281 Seoul 151-744 282 Korea 284 Phone: +82-2-880-1832 285 Fax: +82-2-872-2045 286 Email: hgchoi@mmlab.snu.ac.kr 287 URI: http://mmlab.snu.ac.kr/~hgchoi/