Internet DRAFT - draft-wang-icnrg-icn-edge

draft-wang-icnrg-icn-edge







icnrg                                                            L. Wang
Internet-Draft                                                   L. Geng
Intended status: Informational                              China Mobile
Expires: January 3, 2019                                   July 02, 2018


            Consideration on Applying ICN to Edge Computing
                      draft-wang-icnrg-icn-edge-01

Abstract

   Aiming at research on applying Information Centric Networking (ICN)
   technology to Edge Computing, this document analyzes the reasons and
   opportunities of applying ICN to EC.  As well, towards this end,
   technical considerations are described and relevant scenarios are
   shown in the document.  Benefits of deploying ICN at edge is analyzed
   in the document.

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 https://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 3, 2019.

Copyright Notice

   Copyright (c) 2018 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
   (https://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
   include Simplified BSD License text as described in Section 4.e of




Wang & Geng              Expires January 3, 2019                [Page 1]

Internet-Draft       Information Centric Networking            July 2018


   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Opportunitiesof Applying ICN to EC  . . . . . . . . . . . . .   3
     3.1.  ICN Enable Traffic Convergence  . . . . . . . . . . . . .   3
     3.2.  Functionality Complementary . . . . . . . . . . . . . . .   3
     3.3.  Practicality of ICN Deployment on Edge  . . . . . . . . .   4
   4.  Technical consideration of applying ICN to Edge Computing . .   4
     4.1.  Optimizing EC Network Disconnection Solution  . . . . . .   4
     4.2.  Reducing Traffic Congestion . . . . . . . . . . . . . . .   5
     4.3.  Security Consideration of Using ICN . . . . . . . . . . .   5
     4.4.  Content Centric Networking values edge devices  . . . . .   6
     4.5.  Partial deployment of ICN on Edge . . . . . . . . . . . .   6
   5.  Reverse and Cooperation with CDN  . . . . . . . . . . . . . .   6
   6.  Conclusion  . . . . . . . . . . . . . . . . . . . . . . . . .   8
   7.  Informative References  . . . . . . . . . . . . . . . . . . .   8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   8

1.  Introduction

   Information Centric Networking (ICN) takes significant technical
   revolution and fundamental change on communication and networking.
   It uses content/information centric networking to replace traditional
   address-centric networking which change the existing networking model
   essentially.  It can also be regarded an Internet structure evolution
   from host-centric structure to data-centric structure which means
   accessing data by naming.  This structure enables to make the data
   relating application more independent of its location and
   transmission method.  What's more, security mechanism is based on
   information instead of host and the caching in forwarding process
   that promotes huge information transmission efficiently.  It is very
   promising to apply ICN to some popular network architecture.

   Meanwhile, Edge Computing (EC) is becoming important network
   architecture because of its outstanding performance in real-time,
   reliability, security, etc.  It deploys services on the edge of
   network to be close to consumers, and offers decentralized function
   to enable excellent properties in local computing, storage,
   connectivity and so on.  At present, Edge Computing works broadly on
   IoT and industrial verticals such as Energy, Manufacturing, Smart
   City and Smart Grid.

   Therefore, it is worth attempting the possibility of using ICN on EC.
   ICN naturally supports decentralized caching, self authentication and



Wang & Geng              Expires January 3, 2019                [Page 2]

Internet-Draft       Information Centric Networking            July 2018


   multicast that can enable EC deployment.  The combination of ICN and
   EC is able to offer a win-win approach and benefit mutually for
   maximum performance.  In the following sections, we will seek the
   opportunities of applying ICN to EC, and outline the correlative
   properties of both.  The technical consideration of the approach and
   relevant scenarios will be described as well.

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].

   EC- Edge Computing, an network architecture that provides local
   compute, storage and connectivity services

   Other ICN related words used in this document are interpreted as
   description in [ICNRG-Terminology].

3.  Opportunitiesof Applying ICN to EC

3.1.  ICN Enable Traffic Convergence

   In traditional networks most typical service nodes are deployed in
   centre, so the network flow are transferred from the centre to the
   edge and downlink traffic is dominant.  But as the IoT highly
   developed, a large amount of devices are deployed on the edge, which,
   therefore results in considerable uplink traffic.  The requirement of
   traffic service flattening requests the technique that is able to
   make local communication for traffic convergence.  This could be the
   entry point of applying ICN to EC.

3.2.  Functionality Complementary

   Both ICN and EC possess some correlative properties, such as
   decentralized deployment, local communication capacity, producing
   abundant uplink traffic flow, etc.  However, there are also some
   other properties they posses respectively which are complementary.

   For ICN, caching and forwarding are two basic functions which are
   more about connectivity.  But in practical cases, ICN node devices
   such as gateways demand for light computing and storage functions as
   well.  Light computing and storage can make the network more dynamic,
   flexible and enable some AI deployments as well.  Fortunately, edge
   computing is able to support storage and computing naturally.  A
   combination of both ICN and edge computing can be mutually benefitted
   for maximum performance.




Wang & Geng              Expires January 3, 2019                [Page 3]

Internet-Draft       Information Centric Networking            July 2018


3.3.  Practicality of ICN Deployment on Edge

   TCP/IP network model has been used for quite a while and is worldwide
   deployed now.  No matter according to cost, difficulty, risk or other
   consideration, it is not realistic to deploy ICN on the whole
   network.  However, the partial deployment of ICN can have a chance,
   such as ICN over IP or IP over ICN.  Deploying ICN on edge service
   not only can help to mitigate the ICN whole-network deployment
   complexity, but also makes the network model more flexible.

4.  Technical consideration of applying ICN to Edge Computing

4.1.  Optimizing EC Network Disconnection Solution

   In some scenarios that the network is not able to offer end to end
   communication such as power failure or natural disasters that could
   result in the interruption of the network and other local
   disconnections problems.  Often such failure can cause a series of
   accidents and even chain reaction, resulting in the loss of
   enterprises and production.  In the case, edge computing enable to
   supply service which is closer to the edge of data generation and
   business control deployment, making the computation much closer to
   the data source.  Even if the network fails to get connected, the
   device can rely on local networks for data communication and
   processing.

   However, (a) sometimes the data stored on the edge is "staleness" due
   to incapacity of updating timely.  This could result in the mistake
   or staleness data transmission. (b) Furthermore, the storage space on
   edge is limited.  For instance, it is not able to update new content
   if there is no spare space when storage on edge which normally is
   small storage capacity, is full.  This can also cause the (a)
   problem.

   In ICN network, the content is cached along the path it delivery.  So
   the objective content can be from the source node or the other
   content caching nodes.  When the network is disconnected, the caching
   content or data in decentralized nodes can be used in edge computing.
   Caching algorithm of ICN is able to solve two problems stated in
   previous paragraph by updating data efficiently and dynamically.
   This benefits from the caching replacement policies of ICN.  The
   policies, such as LRU or LFU, provide mechanism how long or how often
   the data will be updated.  Therefore the data is either the newest or
   the most popular.  Decentralized content caching of ICN strengthens
   EC network disconnection solution and make more flexible networking.






Wang & Geng              Expires January 3, 2019                [Page 4]

Internet-Draft       Information Centric Networking            July 2018


4.2.  Reducing Traffic Congestion

   In IoT industry, there are a huge number of devices deployed on the
   edge which result in a significant amount of uplink flow traffic.  In
   EC, the prominent quantity of traffic is easy to cause traffic
   congestion.

   In ICN network, the data content not only from the source node, but
   also it is cached in other nodes along the delivery path.  So when
   the edge node request the data, it is not necessary to deliver data
   from the source node.  For instance, in the figure, if node 1 is
   source node.  When node3 requests data from node1, the content will
   be cached in both node A and node B.  So next time when node4 needs
   the same content data, node B will deliver it, and vice versa.  In
   the case, the traffic is not from node1(source node) to node3 or
   node4 anymore, but mainly from A to B.  Therefore, ICN decentralized
   content caching enable traffic convergence.to reduce traffic
   congestion.


                            Data Traffic
                     +------------------------+
                     |                        |
                  +----+                   +----+
            +-----+ A  +-----+        +----+ B  +------+
            |     +----+     |        |    +----+      |
            |                |        |                |
            |                |        |                |
            |                |        |                |
      +--------+        +-------+   +----+        +------+
      | node 1 |        | node 2|   |node3        node4  |
      +--------+        +-------+   +----+        +------+
      Source Node
   Figure 1

                        Traffic Convergence in ICN

4.3.  Security Consideration of Using ICN

   Security problem is crucial and urgent to the EC applications.
   Firstly, there are many devices on edge are exposed to users which is
   easy to be attacked.  Secondly, although authority level on edge is
   lower than host and cloud, there are more people can get access to
   the devices and application.  This is in consideration of the
   consumer convenience and deployment flexibility.  Hence, application
   and services are vulnerable on edge.





Wang & Geng              Expires January 3, 2019                [Page 5]

Internet-Draft       Information Centric Networking            July 2018


   Instead of binding security to host node, ICN advocates the model of
   trust in content.  This offers host-independent security mechanism
   which focuses more on securing information object and content trust.
   It means host attack no more can interfere edge application.
   Furthermore, self-certify names model of ICN enable to verify the
   binding between public key and self-certify name in distributed
   system without relying on a third party.  This can reduce the
   security risk of involving a third party.

4.4.  Content Centric Networking values edge devices

   No matter ICN or CCN, they all promote content centric communication
   model.  Independent from host node, naming on edge node gain more
   valuation on edge devices.

4.5.  Partial deployment of ICN on Edge

   In consideration of cost and complexity of deploying ICN, it is not
   necessary to use ICN in the whole network.  ICN using on edge is
   enough to highlight its advantage.  Furthermore, there can be a
   corporation between ICN edge service and IP network.

5.  Reverse and Cooperation with CDN

   Content Delivery Network (CDN) system, based on IP, composes a couple
   of servers that deliver content to a user, based on the geographic
   locations of the user, the origin resource and the CND server nodes.
   Normally, the resource is distributed in a downlink traffice in
   figure2.

   However, in a ICN network, resource or origin node is not the central
   node anymore.  An edge device can be the origin node that provides
   the resource which is delivered to ICN servers, and further
   distributed to the receiver nodes.  As a consequence, the routing is
   from edge to central, or there will be an uplink traffic.  This just
   reverses the CDN Mechanism, which is shown in figure3.

   Therefore, deploying ICN network at edge that pulls the requested
   data from resource edge node to the servers can cooperate with CDN
   network.  An ICN/CDN server is anticipated to translate the protocol
   between both and deliver the data to the receiver nodes which can be
   ICN network or IP network.









Wang & Geng              Expires January 3, 2019                [Page 6]

Internet-Draft       Information Centric Networking            July 2018


                     +----------+
                   |Origin/Web|
                   |SerVer    |
                   +---+------+
                       |
             +-------------------+         Traffic
             |         |         |         from origin to edge
             |         |         |         downlink
             |         |         |
             |         |         |
             v         v         v
        +---------+ +-------+  +------+
        |   CDN  ++ | CND   |  |  CND |...
        |   SERVER| | SERVER|  |SERVER|
        ++---+----+ +--+----+  +---+--+
         |   |         |           |
         |   |         |           |
         |   |         |           |
         v   v         v           v
   +-----++ ++----+  +-+---+   +---+---+
   |EDGE  | |EDGE |  |EDGE |...| EDGE  |
   +------+ +-----+  +-----+   +-------+

     Figure2 CDN Mechanism

                                        ICN/CDN SERVER deliver data to receivers

                           +----------+               +------+
               +---------->+ ICN/CDN SERVE+---------->+Receiver
               ^           |          |   |           +Node--+
               |           +----------+   |
               |                          |           +------+
               |                          +---------->+Receiver
          +----+-----+                                +Node--+
          | ICN server
          +-+--------+
            ^      ^
            |      | Traffic from Edge to ICN server
            |      | uplink, reversed CND
            |      |
        +---++   +-+--+
EdgeNode|Origin  |    |
        |Resource|    |
        +----+   +----+



Figure3 ICN Mechanism



Wang & Geng              Expires January 3, 2019                [Page 7]

Internet-Draft       Information Centric Networking            July 2018


6.  Conclusion

   This draft described the correlative properties of ICN and EC to
   analyze the opportunity of applying ICN to edge computing.  The
   traffic uplink flow model is the entry point of this research.  We
   could see ICN deployment is beneficial to EC by combining the
   outstanding performances of both.  Furthermore, a win-win model is
   schemed in the document by means of mutual complementing.  However,
   there are still challenges on deploying ICN on edge such as high
   speed mobility, fast context resolution and so on.  These questions
   need to be answered in the future.

7.  Informative References

   [I-D.boucadair-connectivity-provisioning-protocol]
              Boucadair, M., Jacquenet, C., Zhang, D., and P.
              Georgatsos, "Connectivity Provisioning Negotiation
              Protocol (CPNP)", draft-boucadair-connectivity-
              provisioning-protocol-15 (work in progress), December
              2017.

   [ICNRG-Terminology]
              "Information-Centric Networking (ICN): CCN and NDN
              Terminology", <https://datatracker.ietf.org/doc/
              draft-irtf-icnrg-terminology/>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC5440]  Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
              Element (PCE) Communication Protocol (PCEP)", RFC 5440,
              DOI 10.17487/RFC5440, March 2009,
              <https://www.rfc-editor.org/info/rfc5440>.

Authors' Addresses

   Lei Wang
   China Mobile
   Beijing  100053
   China

   Email: jifengyiwl@163.com







Wang & Geng              Expires January 3, 2019                [Page 8]

Internet-Draft       Information Centric Networking            July 2018


   Liang Geng
   China Mobile
   Beijing  100053
   China

   Email: gengliang@chinamobile.com













































Wang & Geng              Expires January 3, 2019                [Page 9]