[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00

Network Working Group                                        E. Nordmark
Internet-Draft                                                    Zededa
Intended status: Standards Track                        October 22, 2018
Expires: April 25, 2019

                         Computing at the edge


   There has been some discussion about edge computing in the T2TRG.
   This note explores the edge from a computing perspective, and from
   that suggests aspects of networking that relate to edge computing.
   It includes some potential research problems for networking edge

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 April 25, 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
   (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
   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.

Nordmark                 Expires April 25, 2019                 [Page 1]

Internet-Draft                idloc privacy                 October 2018

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  What is computing?  . . . . . . . . . . . . . . . . . . . . .   2
   3.  What is edge? . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Why edge computing? . . . . . . . . . . . . . . . . . . . . .   4
   5.  Networking for Edge Computing . . . . . . . . . . . . . . . .   5
   6.  Application connectivity  . . . . . . . . . . . . . . . . . .   5
   7.  Potential research topics . . . . . . . . . . . . . . . . . .   6
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   10. Informative References  . . . . . . . . . . . . . . . . . . .   7
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   7

1.  Introduction

   Edge computing has gained increased interest industry over the last
   few years and there has already been some discussion in the IETF and
   IRTF as exemplified by [I-D.zhang-iiot-edge-computing-gap-analysis],
   [I-D.hong-iot-edge-computing], and
   [I-D.geng-iiot-edge-computing-problem-statement].  This note builds
   on that work while taking a step back from the networking aspects to
   look at how computing would happen at the edge and what is needed to
   satisfy that computing.  The note also tries to separate out the
   motivations for computing edge from the attributes of the edge.

2.  What is computing?

   The general notion of computing is likely to be clear; some
   programmable ability in the form of CPU/GPU plus some memory, with
   some ability to interact with the external word (I/O, networking),
   with optional ability to store data locally with persistence.

   However, it might be useful to try to separate the flexibility of
   edge computing from fixed function devices which do not have the
   capacity or flexibility to perform other functions than envisioned
   prior to their deployment.  Such fixed function devices still require
   a software/firmware update capability as discussed in [RFC8240], but
   they do not require handling new application deployment and
   associated new communication patterns.

   These more flexible devices are likely to be larger than the class 2
   devices defined in [RFC7228], however if applications are
   sufficiently small, constrained devices might very well be edge
   computing devices.  But in general it makes sense to think about
   devices of the Raspberry Pi class and larger.

Nordmark                 Expires April 25, 2019                 [Page 2]

Internet-Draft                idloc privacy                 October 2018

   If the set of applications which might be deployed on a device isn't
   known prior to deployment it might be difficult to determine a
   utility cycle and resulting upper bound on power consumption.  As
   such it is hard to envision this flexibility for devices which need
   to run for years on a battery or using energy harvesting.

   One way to envision edge computing is to think of a developer or a
   devops person wanting to run computation closer to the sensors and
   actuators, but with the same ease as running computation in the cloud
   (e.g, docker, kubernetes).  In that vein one can think of existing
   applications with a new deployment target; deploy to all the light-
   poles in Palo Alto as opposed to a cloud availability zone.  Of
   course the industry will also develop new applications and new
   applications for the edge, but some applications are likely to
   migrate from the cloud or be existing standalone applications.

   In some cases it is useful to make a distinction between a device and
   an (IoT) gateway in this context.  However, the term gateway might
   mean very different things.  In some cases it is a product category,
   referring to compact and passively cooled PCs with rich physical
   connectivity e.g., RS485 ports and multiple Ethernet ports, etc.
   That generalizes to an architectural node which has a router and
   protocol translators e.g., from Modbus to MQTT.  In other cases it
   refers to nodes which run software to translate one data model to
   another one as in [I-D.iab-iotsi-workshop].

   We might see architectural patterns in the future which separate
   fixed function devices (in particular those with hardware crypto
   implementations) with long deployment lifetimes from the larger
   Internet and its threats and need for crypto agility by interposing a
   "gateway" device which limits the security exposure for those fixed
   function devices.  However, we have yet to see that architectural
   pattern develop.

3.  What is edge?

   As edge computing is gaining popularity the term seems to be applied
   to refer to a large range of things:

   o  In the context of Industry 4.0 the edge is where the actions are
      to be taken based on the analyzed data, thus in or near the
      machines in the factory.
   o  The Industrial Internet Consortium (IIC) refers to the edge as
      customer premise equipment i.e., equipment deployed in the
   o  ETSI MEC refers to the edge of provider network, i.e., the
      provider edge.

Nordmark                 Expires April 25, 2019                 [Page 3]

Internet-Draft                idloc privacy                 October 2018

   o  Some datacenter operators with many smaller datacenters offer edge
      computing solutions since they claim being closer to the users
      than the large cloud operators.
   o  There is also the Internet Edge (where the large Content Delivery
      Networks tend to be deployed) and the datacenter edge.

   From an architectural perspective what matters is not the term but
   what the characteristics are.  As you move further and further out
   towards the premises and enterprises some new characteristics appear
   compared to running inside a datacenter, large or small.  These apply
   to varying degrees whether that edge device is in a light pole in a
   smart city, on a factory floor, on an oil rig, or on a truck.

   o  Less physical security - not the same physical access control.
   o  Different network security - there might not be a firewall between
      it and the Internet
   o  (Physical) location is key in many cases; need to be in BTLE range
      or have the camera pointing at the right road intersection.
   o  Scale is likely to be much larger than the cloud datacenters
      because devices need to exist in all the locations which matter.
   o  Less network transparency; NATs and/or firewalls could exist
      between the elements of the computation at the edge.
   o  Richer uplink networking (such as Ethernet, LTE, WiFi, etc).
      Might have redundant uplinks using different technologies.
   o  Might require specific downlink connectivity (6lo, BTLE, RS485,
   o  Intermittent connectivity more likely than inside datacenter.
   o  Normally no fallback network such as serial console, management
      network, or remote power control to handle software updates gone

4.  Why edge computing?

   The benefits of moving computing closer the sensors and actuators
   seems to fall in three categories:

   o  Lower latency, for instance to handle process control where
      decisions need to be made locally.
   o  Cost of bandwidth.  In many cases sending all the data to the
      cloud to perform data aggregation and run analytics can get quite
      expensive compared to local aggregation and analytics.
   o  Autonomy and failure resiliency.  A machine on the factory floor
      needs to continue to work even if the Internet/cloud connectivity
      is temporarily out.

   Some documents also mention data jurisdiction as a key benefit.  That
   seems to be more an issue with keeping the data in the same

Nordmark                 Expires April 25, 2019                 [Page 4]

Internet-Draft                idloc privacy                 October 2018

   enterprise and same country and the data origin, and not about
   keeping it as close as possible to the sensors and actuators.

5.  Networking for Edge Computing

   From the above list several of the different attributes between the
   datacenter and the edge are about connectivity.  In general the
   connectivity is a lot more diverse at the edge than in the

   Solutions need to handle at least Ethernet, WiFi, LTE, IPv4/IPv6,
   redundant/multihomed connectivity, mobility, and NATs.  Ideally the
   applications which are deployed at the edge should not be required to
   handle this diversity but instead operate the same as in the cloud
   where the applications see DNS and IP connectivity.

   In addition, if the applications are structured as communicating
   (micro) services when deployed in the cloud, they are likely to
   assume some level of network isolation (security groups etc) from the
   infrastructure.  In order to be able to deploy such applications at
   the edge the infrastructure needs to provide at least the same level
   of isolation, and due to the more challenging security environment at
   the edge, it probably needs to be stronger.

6.  Application connectivity

   Earlier work [RFC7452] outlines three different communication

   o  Device-to-Device Communication Pattern
   o  Device-to-Cloud Communication Pattern
   o  Device-to-Gateway Communication Pattern

   For the purposes of this note we separate the Device-to-Device
   pattern into a topology-specific pattern and a topology independent.

   The topology-specific D2D pattern is where a set of devices are e.g.,
   on the same link hence can make assumptions about discovery and
   security that are related to the link's properties.  Such deployments
   are common today for certain applications.

   The topology-independent D2D pattern is examplified by an application
   deployment pattern where one microservice needs e.g., a GPU for
   running a model and the GPU might exist in the same building or site
   but on a different network perhaps separated by NATs.  To enable the
   promise of flexibility for edge computing the infrastructure needs to
   be able to support such a communication pattern, which places new

Nordmark                 Expires April 25, 2019                 [Page 5]

Internet-Draft                idloc privacy                 October 2018

   requirements on discovery and security even when all of the edge
   infrastructure is under common administrative control.

   The Device-to-Cloud Communication Pattern [RFC7452] is commonly being
   deployed today, but does not necessarily handle the applications with
   real-time considerations.

   The Device-to-Gateway Communication Pattern [RFC7452] can mean
   different things depending on what type of gateway is at play.  In
   current deployment it seems to imply that the application topology is
   the same as the network topology.  For instance, the devices connect
   over one protocol to a gateway, and that physical gateway is the only
   one which can run the applications (be they simple protocol
   translators or analytics/AI) which serve those devices.  Over time
   one would expect to see the application/micro-service topology to be
   unrelated to the network topology; that is how the datacenter and
   cloud has evolved.

7.  Potential research topics

   As discussed in the previous section there are likely to be
   additional needs to enable micro-services at the edge which has the
   different attributes we have identified.  However, most of that might
   be an engineering exercise.

   That assumes a single asset owner controlling some set of devices,
   gateways, and compute elements.  In the case of that asset owner
   leasing space for VMs or containers those technologies as used in the
   cloud can be reused for multi-tenancy.  However, orchestration might
   need to be different due to the importance of location for edge

   If we envision a future where we want to enable more flexible
   resource sharing, e.g., shop owners on a street in Sao Paulo be able
   to offer their spare CPU and GPU capacity to their neighbors with
   some compensation/tokens, there will be additional issues around
   trust, compensation, discovery, etc.

8.  Security Considerations

   This note touches on both system security and communication security.

9.  IANA Considerations

   There are no IANA actions needed for this document.

Nordmark                 Expires April 25, 2019                 [Page 6]

Internet-Draft                idloc privacy                 October 2018

10.  Informative References

   [RFC7228]  Bormann, C., Ersue, M., and A. Keranen, "Terminology for
              Constrained-Node Networks", RFC 7228,
              DOI 10.17487/RFC7228, May 2014, <https://www.rfc-

   [RFC7452]  Tschofenig, H., Arkko, J., Thaler, D., and D. McPherson,
              "Architectural Considerations in Smart Object Networking",
              RFC 7452, DOI 10.17487/RFC7452, March 2015,

   [RFC8240]  Tschofenig, H. and S. Farrell, "Report from the Internet
              of Things Software Update (IoTSU) Workshop 2016",
              RFC 8240, DOI 10.17487/RFC8240, September 2017,

              Jimenez, J., Tschofenig, H., and D. Thaler, "Report from
              the Internet of Things (IoT) Semantic Interoperability
              (IOTSI) Workshop 2016", draft-iab-iotsi-workshop-02 (work
              in progress), July 2018.

              Zhang, M., Liu, B., McBride, M., Hu, C., and L. Geng, "Gap
              Analysis of Edge Computing for Industrial IoT", draft-
              zhang-iiot-edge-computing-gap-analysis-00 (work in
              progress), March 2018.

              Hong, J., Hong, Y., and J. Youn, "Problem Statement of IoT
              integrated with Edge Computing", draft-hong-iot-edge-
              computing-01 (work in progress), October 2018.

              Geng, L., Zhang, M., McBride, M., and B. Liu, "Problem
              Statement of Edge Computing on Premises for Industrial
              IoT", draft-geng-iiot-edge-computing-problem-statement-01
              (work in progress), March 2018.

Author's Address

   Erik Nordmark
   Santa Clara, CA

   Email: nordmark@sonic.net

Nordmark                 Expires April 25, 2019                 [Page 7]

Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/