idnits 2.17.1
draft-wang-icnrg-icn-edge-01.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 issues found here.
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.)
** There is 1 instance of too long lines in the document, the longest one
being 8 characters in excess of 72.
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 02, 2018) is 2126 days in the past. Is this
intentional?
Checking references for intended status: Informational
----------------------------------------------------------------------------
== Unused Reference: 'I-D.boucadair-connectivity-provisioning-protocol' is
defined on line 339, but no explicit reference was found in the text
== Unused Reference: 'RFC5440' is defined on line 356, but no explicit
reference was found in the text
== Outdated reference: A later version (-22) exists of
draft-boucadair-connectivity-provisioning-protocol-15
Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 icnrg L. Wang
3 Internet-Draft L. Geng
4 Intended status: Informational China Mobile
5 Expires: January 3, 2019 July 02, 2018
7 Consideration on Applying ICN to Edge Computing
8 draft-wang-icnrg-icn-edge-01
10 Abstract
12 Aiming at research on applying Information Centric Networking (ICN)
13 technology to Edge Computing, this document analyzes the reasons and
14 opportunities of applying ICN to EC. As well, towards this end,
15 technical considerations are described and relevant scenarios are
16 shown in the document. Benefits of deploying ICN at edge is analyzed
17 in the document.
19 Status of This Memo
21 This Internet-Draft is submitted in full conformance with the
22 provisions of BCP 78 and BCP 79.
24 Internet-Drafts are working documents of the Internet Engineering
25 Task Force (IETF). Note that other groups may also distribute
26 working documents as Internet-Drafts. The list of current Internet-
27 Drafts is at https://datatracker.ietf.org/drafts/current/.
29 Internet-Drafts are draft documents valid for a maximum of six months
30 and may be updated, replaced, or obsoleted by other documents at any
31 time. It is inappropriate to use Internet-Drafts as reference
32 material or to cite them other than as "work in progress."
34 This Internet-Draft will expire on January 3, 2019.
36 Copyright Notice
38 Copyright (c) 2018 IETF Trust and the persons identified as the
39 document authors. All rights reserved.
41 This document is subject to BCP 78 and the IETF Trust's Legal
42 Provisions Relating to IETF Documents
43 (https://trustee.ietf.org/license-info) in effect on the date of
44 publication of this document. Please review these documents
45 carefully, as they describe your rights and restrictions with respect
46 to this document. Code Components extracted from this document must
47 include Simplified BSD License text as described in Section 4.e of
48 the Trust Legal Provisions and are provided without warranty as
49 described in the Simplified BSD License.
51 Table of Contents
53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
55 3. Opportunitiesof Applying ICN to EC . . . . . . . . . . . . . 3
56 3.1. ICN Enable Traffic Convergence . . . . . . . . . . . . . 3
57 3.2. Functionality Complementary . . . . . . . . . . . . . . . 3
58 3.3. Practicality of ICN Deployment on Edge . . . . . . . . . 4
59 4. Technical consideration of applying ICN to Edge Computing . . 4
60 4.1. Optimizing EC Network Disconnection Solution . . . . . . 4
61 4.2. Reducing Traffic Congestion . . . . . . . . . . . . . . . 5
62 4.3. Security Consideration of Using ICN . . . . . . . . . . . 5
63 4.4. Content Centric Networking values edge devices . . . . . 6
64 4.5. Partial deployment of ICN on Edge . . . . . . . . . . . . 6
65 5. Reverse and Cooperation with CDN . . . . . . . . . . . . . . 6
66 6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 8
67 7. Informative References . . . . . . . . . . . . . . . . . . . 8
68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
70 1. Introduction
72 Information Centric Networking (ICN) takes significant technical
73 revolution and fundamental change on communication and networking.
74 It uses content/information centric networking to replace traditional
75 address-centric networking which change the existing networking model
76 essentially. It can also be regarded an Internet structure evolution
77 from host-centric structure to data-centric structure which means
78 accessing data by naming. This structure enables to make the data
79 relating application more independent of its location and
80 transmission method. What's more, security mechanism is based on
81 information instead of host and the caching in forwarding process
82 that promotes huge information transmission efficiently. It is very
83 promising to apply ICN to some popular network architecture.
85 Meanwhile, Edge Computing (EC) is becoming important network
86 architecture because of its outstanding performance in real-time,
87 reliability, security, etc. It deploys services on the edge of
88 network to be close to consumers, and offers decentralized function
89 to enable excellent properties in local computing, storage,
90 connectivity and so on. At present, Edge Computing works broadly on
91 IoT and industrial verticals such as Energy, Manufacturing, Smart
92 City and Smart Grid.
94 Therefore, it is worth attempting the possibility of using ICN on EC.
95 ICN naturally supports decentralized caching, self authentication and
96 multicast that can enable EC deployment. The combination of ICN and
97 EC is able to offer a win-win approach and benefit mutually for
98 maximum performance. In the following sections, we will seek the
99 opportunities of applying ICN to EC, and outline the correlative
100 properties of both. The technical consideration of the approach and
101 relevant scenarios will be described as well.
103 2. Terminology
105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
107 document are to be interpreted as described in [RFC2119].
109 EC- Edge Computing, an network architecture that provides local
110 compute, storage and connectivity services
112 Other ICN related words used in this document are interpreted as
113 description in [ICNRG-Terminology].
115 3. Opportunitiesof Applying ICN to EC
117 3.1. ICN Enable Traffic Convergence
119 In traditional networks most typical service nodes are deployed in
120 centre, so the network flow are transferred from the centre to the
121 edge and downlink traffic is dominant. But as the IoT highly
122 developed, a large amount of devices are deployed on the edge, which,
123 therefore results in considerable uplink traffic. The requirement of
124 traffic service flattening requests the technique that is able to
125 make local communication for traffic convergence. This could be the
126 entry point of applying ICN to EC.
128 3.2. Functionality Complementary
130 Both ICN and EC possess some correlative properties, such as
131 decentralized deployment, local communication capacity, producing
132 abundant uplink traffic flow, etc. However, there are also some
133 other properties they posses respectively which are complementary.
135 For ICN, caching and forwarding are two basic functions which are
136 more about connectivity. But in practical cases, ICN node devices
137 such as gateways demand for light computing and storage functions as
138 well. Light computing and storage can make the network more dynamic,
139 flexible and enable some AI deployments as well. Fortunately, edge
140 computing is able to support storage and computing naturally. A
141 combination of both ICN and edge computing can be mutually benefitted
142 for maximum performance.
144 3.3. Practicality of ICN Deployment on Edge
146 TCP/IP network model has been used for quite a while and is worldwide
147 deployed now. No matter according to cost, difficulty, risk or other
148 consideration, it is not realistic to deploy ICN on the whole
149 network. However, the partial deployment of ICN can have a chance,
150 such as ICN over IP or IP over ICN. Deploying ICN on edge service
151 not only can help to mitigate the ICN whole-network deployment
152 complexity, but also makes the network model more flexible.
154 4. Technical consideration of applying ICN to Edge Computing
156 4.1. Optimizing EC Network Disconnection Solution
158 In some scenarios that the network is not able to offer end to end
159 communication such as power failure or natural disasters that could
160 result in the interruption of the network and other local
161 disconnections problems. Often such failure can cause a series of
162 accidents and even chain reaction, resulting in the loss of
163 enterprises and production. In the case, edge computing enable to
164 supply service which is closer to the edge of data generation and
165 business control deployment, making the computation much closer to
166 the data source. Even if the network fails to get connected, the
167 device can rely on local networks for data communication and
168 processing.
170 However, (a) sometimes the data stored on the edge is "staleness" due
171 to incapacity of updating timely. This could result in the mistake
172 or staleness data transmission. (b) Furthermore, the storage space on
173 edge is limited. For instance, it is not able to update new content
174 if there is no spare space when storage on edge which normally is
175 small storage capacity, is full. This can also cause the (a)
176 problem.
178 In ICN network, the content is cached along the path it delivery. So
179 the objective content can be from the source node or the other
180 content caching nodes. When the network is disconnected, the caching
181 content or data in decentralized nodes can be used in edge computing.
182 Caching algorithm of ICN is able to solve two problems stated in
183 previous paragraph by updating data efficiently and dynamically.
184 This benefits from the caching replacement policies of ICN. The
185 policies, such as LRU or LFU, provide mechanism how long or how often
186 the data will be updated. Therefore the data is either the newest or
187 the most popular. Decentralized content caching of ICN strengthens
188 EC network disconnection solution and make more flexible networking.
190 4.2. Reducing Traffic Congestion
192 In IoT industry, there are a huge number of devices deployed on the
193 edge which result in a significant amount of uplink flow traffic. In
194 EC, the prominent quantity of traffic is easy to cause traffic
195 congestion.
197 In ICN network, the data content not only from the source node, but
198 also it is cached in other nodes along the delivery path. So when
199 the edge node request the data, it is not necessary to deliver data
200 from the source node. For instance, in the figure, if node 1 is
201 source node. When node3 requests data from node1, the content will
202 be cached in both node A and node B. So next time when node4 needs
203 the same content data, node B will deliver it, and vice versa. In
204 the case, the traffic is not from node1(source node) to node3 or
205 node4 anymore, but mainly from A to B. Therefore, ICN decentralized
206 content caching enable traffic convergence.to reduce traffic
207 congestion.
209 Data Traffic
210 +------------------------+
211 | |
212 +----+ +----+
213 +-----+ A +-----+ +----+ B +------+
214 | +----+ | | +----+ |
215 | | | |
216 | | | |
217 | | | |
218 +--------+ +-------+ +----+ +------+
219 | node 1 | | node 2| |node3 node4 |
220 +--------+ +-------+ +----+ +------+
221 Source Node
222 Figure 1
224 Traffic Convergence in ICN
226 4.3. Security Consideration of Using ICN
228 Security problem is crucial and urgent to the EC applications.
229 Firstly, there are many devices on edge are exposed to users which is
230 easy to be attacked. Secondly, although authority level on edge is
231 lower than host and cloud, there are more people can get access to
232 the devices and application. This is in consideration of the
233 consumer convenience and deployment flexibility. Hence, application
234 and services are vulnerable on edge.
236 Instead of binding security to host node, ICN advocates the model of
237 trust in content. This offers host-independent security mechanism
238 which focuses more on securing information object and content trust.
239 It means host attack no more can interfere edge application.
240 Furthermore, self-certify names model of ICN enable to verify the
241 binding between public key and self-certify name in distributed
242 system without relying on a third party. This can reduce the
243 security risk of involving a third party.
245 4.4. Content Centric Networking values edge devices
247 No matter ICN or CCN, they all promote content centric communication
248 model. Independent from host node, naming on edge node gain more
249 valuation on edge devices.
251 4.5. Partial deployment of ICN on Edge
253 In consideration of cost and complexity of deploying ICN, it is not
254 necessary to use ICN in the whole network. ICN using on edge is
255 enough to highlight its advantage. Furthermore, there can be a
256 corporation between ICN edge service and IP network.
258 5. Reverse and Cooperation with CDN
260 Content Delivery Network (CDN) system, based on IP, composes a couple
261 of servers that deliver content to a user, based on the geographic
262 locations of the user, the origin resource and the CND server nodes.
263 Normally, the resource is distributed in a downlink traffice in
264 figure2.
266 However, in a ICN network, resource or origin node is not the central
267 node anymore. An edge device can be the origin node that provides
268 the resource which is delivered to ICN servers, and further
269 distributed to the receiver nodes. As a consequence, the routing is
270 from edge to central, or there will be an uplink traffic. This just
271 reverses the CDN Mechanism, which is shown in figure3.
273 Therefore, deploying ICN network at edge that pulls the requested
274 data from resource edge node to the servers can cooperate with CDN
275 network. An ICN/CDN server is anticipated to translate the protocol
276 between both and deliver the data to the receiver nodes which can be
277 ICN network or IP network.
279 +----------+
280 |Origin/Web|
281 |SerVer |
282 +---+------+
283 |
284 +-------------------+ Traffic
285 | | | from origin to edge
286 | | | downlink
287 | | |
288 | | |
289 v v v
290 +---------+ +-------+ +------+
291 | CDN ++ | CND | | CND |...
292 | SERVER| | SERVER| |SERVER|
293 ++---+----+ +--+----+ +---+--+
294 | | | |
295 | | | |
296 | | | |
297 v v v v
298 +-----++ ++----+ +-+---+ +---+---+
299 |EDGE | |EDGE | |EDGE |...| EDGE |
300 +------+ +-----+ +-----+ +-------+
302 Figure2 CDN Mechanism
304 ICN/CDN SERVER deliver data to receivers
306 +----------+ +------+
307 +---------->+ ICN/CDN SERVE+---------->+Receiver
308 ^ | | | +Node--+
309 | +----------+ |
310 | | +------+
311 | +---------->+Receiver
312 +----+-----+ +Node--+
313 | ICN server
314 +-+--------+
315 ^ ^
316 | | Traffic from Edge to ICN server
317 | | uplink, reversed CND
318 | |
319 +---++ +-+--+
320 EdgeNode|Origin | |
321 |Resource| |
322 +----+ +----+
324 Figure3 ICN Mechanism
325 6. Conclusion
327 This draft described the correlative properties of ICN and EC to
328 analyze the opportunity of applying ICN to edge computing. The
329 traffic uplink flow model is the entry point of this research. We
330 could see ICN deployment is beneficial to EC by combining the
331 outstanding performances of both. Furthermore, a win-win model is
332 schemed in the document by means of mutual complementing. However,
333 there are still challenges on deploying ICN on edge such as high
334 speed mobility, fast context resolution and so on. These questions
335 need to be answered in the future.
337 7. Informative References
339 [I-D.boucadair-connectivity-provisioning-protocol]
340 Boucadair, M., Jacquenet, C., Zhang, D., and P.
341 Georgatsos, "Connectivity Provisioning Negotiation
342 Protocol (CPNP)", draft-boucadair-connectivity-
343 provisioning-protocol-15 (work in progress), December
344 2017.
346 [ICNRG-Terminology]
347 "Information-Centric Networking (ICN): CCN and NDN
348 Terminology", .
351 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
352 Requirement Levels", BCP 14, RFC 2119,
353 DOI 10.17487/RFC2119, March 1997,
354 .
356 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
357 Element (PCE) Communication Protocol (PCEP)", RFC 5440,
358 DOI 10.17487/RFC5440, March 2009,
359 .
361 Authors' Addresses
363 Lei Wang
364 China Mobile
365 Beijing 100053
366 China
368 Email: jifengyiwl@163.com
369 Liang Geng
370 China Mobile
371 Beijing 100053
372 China
374 Email: gengliang@chinamobile.com