Internet DRAFT - draft-liu-iiot-sfc-edge-computing-applicability

draft-liu-iiot-sfc-edge-computing-applicability







Industrial Internet of Things                                     B. Liu
Internet-Draft                                               K. Katsalis
Intended status: Informational                                  M. Zhang
Expires: April 24, 2019                              Huawei Technologies
                                                        October 21, 2018


  Service Function Chaining Applicability in Industrial Edge Computing
           draft-liu-iiot-sfc-edge-computing-applicability-00

Abstract

   Decoupling functions from the industrial hardware enables diverse,
   migratable, cross-industry replicable applications to be deployed
   with flexibility at the edge and on the cloud.  Users should be free
   to adjust their business policies in industrial IoT and with low
   cost.  Therefore efficient and dynamic orchestration of the
   applications is critical.  This document describes several use cases
   that demonstrate the applicability of Service Function Chaining in
   industrial edge computing to organize the applications and provides
   extra requirements to support this applicability.

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 April 24, 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



Liu, et al.              Expires April 24, 2019                 [Page 1]

Internet-Draft      SFC in Industrial Edge Computing        October 2018


   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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Industrial Edge Computing Overview  . . . . . . . . . . . . .   4
   4.  Function Deployment Constraints . . . . . . . . . . . . . . .   6
     4.1.  Node Capability Constraints . . . . . . . . . . . . . . .   6
     4.2.  Performance Constraints . . . . . . . . . . . . . . . . .   7
     4.3.  Privacy Constraints . . . . . . . . . . . . . . . . . . .   7
   5.  SFC for Edge Computing use case . . . . . . . . . . . . . . .   7
     5.1.  Building paths from chains  . . . . . . . . . . . . . . .   9
     5.2.  Selecting a path  . . . . . . . . . . . . . . . . . . . .  10
     5.3.  Path redirection  . . . . . . . . . . . . . . . . . . . .  11
   6.  Applicability Requirements  . . . . . . . . . . . . . . . . .  11
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  11
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  11
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  11
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  12
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  12

1.  Introduction

   Cloudification has become a consensus trend in many domains due to
   the low cost, high scalability and reliability of the cloud.
   However, cloudification may not be easy or applicable for all aspects
   of industrial internet of things.  In order to achieve control
   stability, an input must be given to the system with a bounded
   latency.  For example, the control loop of a robotic arm can be 10ms,
   in which time the system must acquire the sensors' signals, compute
   the input and send it to the actuators.  Deploying the controller
   remotely on the cloud is not practical because the round trip of
   signals is too time consuming, and packet loss will lead to
   instability.  Besides, transmitting all the raw data to the cloud is
   not economical: VPNs or reserved bandwidth needs much more
   expenditure.  In addition, industrial data is so sensitive that the
   owners of the data are not willing to expose it on the public
   Internet.  Sending the raw data to the cloud presents such a risk.

   The concept of edge computing, i.e. providing networking, compute and
   storage capabilities close to the data source, is promising to deal
   with the aforementioned requirements.  Time sensitive applications



Liu, et al.              Expires April 24, 2019                 [Page 2]

Internet-Draft      SFC in Industrial Edge Computing        October 2018


   are deployed at the edge to achieve fast response.  The raw data is
   processed, filtered, or compressed, hence the size could be reduced
   and the privacy data stays under control of users.  A more detailed
   introduction to edge computing can be found in
   [I-D.zhang-iiot-edge-computing-gap-analysis] and
   [I-D.geng-iiot-edge-computing-problem-statement].

   Tomorrow will be the era of edge cloud orchestration, where the edge
   computing and cloud computing work together to meet the various
   requirements of users.  Diverse applications will be deployed at the
   edge and on the cloud.  How to deploy them correctly to realize the
   industry users' policies, and how to manage the applications
   efficiently when the policy changes, are currently open questions.
   Since the edge is the ingress of data, when the data from different
   sensors arrive at the edge computing device, the set of applications
   that the data will go through should be indicated according to the
   preset policies.  After the processing by an application, the output
   data must be forwarded to the correct next hop.  Except the
   applications which have to be deployed at the edge or the cloud due
   to response time and processing resource requirements, multiple
   copies of applications can be deployed at different locations, which
   permit the offload of the tasks to other copies of the application
   when one copy is busy or over utilized.

   Service Function Chaining could be a suitable way to organize the
   edge and cloud applications.  The architecture in [RFC7665] realizes
   the decoupling of the service plane and forwarding plane, making it
   easier to add or delete one application or adjust the order of their
   invocation.  In the data plane, the NSH header helps enhance the
   logical connection between the applications.  The classifier in SFC,
   which decides the path to forward traffic through, matches the
   requirement of task indication.  For the same SFC, different paths
   can be deployed as backups to each other.  When one path is disrupted
   or fully loaded, the work can be offloaded to another path yet have
   the same set of functions applied to it.

   This document describes the idea of using SFC in industrial edge
   computing to organize the applications according to user defined
   policies.  Use cases are given as examples to help explain the idea.

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 RFC 2119 [RFC2119].

   ECN




Liu, et al.              Expires April 24, 2019                 [Page 3]

Internet-Draft      SFC in Industrial Edge Computing        October 2018


      Edge Computing Node: An abstract appellation of devices with edge
      computing capabilities.  In industrial domain, an edge computing
      device can be a logic controller, a gateway, or a local server
      cluster, etc.  An edge computing node MAY act as the physical
      carrier of classifier, SFs and/or SFFs.

   Service Function Chain
      A service function chain defines an ordered set of abstract
      service functions and ordering constraints that must be applied to
      packets and/or frames and/or flows selected as a result of
      classification.

   Service Function
      An SF in SFC can be mapped to an application in edge computing.

3.  Industrial Edge Computing Overview

   Industrial edge computing can be deployed in a hierarchical way.  For
   example, in manufacturing industry, the scope of group can refer to a
   pipeline, and the scope of campus can refer to a factory.  The data
   comes from the end devices, such as sensors, actuators, equipment,
   assets, etc.  The end devices can be edge computing capable or
   incapable.  A group of end devices (e.g. geographical neighbors) are
   connected to an edge gateway.  The edge gateway offers connectivity
   to the wide area network and may offer connectivity among the end
   devices.  Normally, the resources on an edge gateway are constrained,
   hence the gateway can only handle relatively simple, deterministic or
   dedicated tasks:

   o  Local data processing: aggregation, filtering, translation,
      consolidation and analytics.

   o  Local control/reasoning logic: automation control, decision-
      making, fault detection, and so on.  The parameters/models are
      optimized/trained on the cloud, then assigned to the edge.

   o  Device management: edge gateway acts as the local assets manager
      and enables remote assets management via the wide area network.

   At the campus level, an edge cloud server with more resources may be
   deployed.  Since more resources are provided, relatively complex
   tasks can be handled, such as:

   o  Operation management: translating upper layer abstract commands
      into operational commands of end devices, updating parameters,
      organizing new work flows, etc.





Liu, et al.              Expires April 24, 2019                 [Page 4]

Internet-Draft      SFC in Industrial Edge Computing        October 2018


   o  Data desensitization: users are not willing to expose their
      sensitive data to the public Internet, thus before uploading the
      sensitive data must be fuzzified.

   o  Data logging: the edge cloud server may have larger storage, hence
      it is preferred to perform the data logging at the server,
      especially when the data is large or needs to be stored for long
      time.

   o  Task offloading: when the edge gateway is over loaded, some tasks
      originally being conducted at the gateways can be transferred to
      the edge cloud if possible.

   The campus network is connected to the cloud via an overlay private
   network over the public network.  The cloud can be private/public
   which implements the company's or third-party regulatory authority's
   applications.  The applications deployed on the cloud are usually
   computationally intensive and require mass storage.  These
   applications involve big data analysis, MES, ERP, CRM, etc.

   It should be clarified that the aforementioned applications and the
   hierarchy to deploy them are just examples.  The actual deployment
   depends on the use cases and requirements.




























Liu, et al.              Expires April 24, 2019                 [Page 5]

Internet-Draft      SFC in Industrial Edge Computing        October 2018


                        +------------------+
                        |                  |
                        |       Cloud      |
                        |                  |
                        +---------+--------+
                                  |
                                  |                   ..................
                              _,..+.._                .Campus 2        .
                           ,-'        `-.             .+--------------+.
                          /              `.           .|              |.
                         |     Network    |+-----------+  Edge Cloud  |.
                         `.              /            .|              |.
                           `.__     __,-'             .+--------------+.
                               `''+'                  ..................
   ...............................|........................
   .Campus 1                      |                       .
   .                      +-------+------+                .
   .                      |              |                .
   .                      |  Edge Cloud  |                .
   .                      |              |                .
   .                      +-------+------+                .
   .                              |                       .
   .               +--------------+---------------+       .
   .               |                              |       .
   .*--------------|--------------*       *-------|------*.
   .|       +------+-----+        |       |+------+-----+|.
   .|       |Edge Gateway|        |       ||Edge Gateway||.
   .|       +------+-----+        |       |+------+-----+|.
   .|              |              |       |       |      |.
   .|      +-------+-------+      |       |       |      |.
   .|      |               |      |       |       |      |.
   .|+-----+----+    +-----+----+ |       | +-----+----+ |.
   .||End Device|    |End Device| |       | |End Device| |.
   .|+----------+    +----------+ |       | +----------+ |.
   .|          Group 1            |       |    Group 2   |.
   .*-----------------------------*       *--------------*.
   ........................................................

            Figure 1: Hierarchical Deployment of Edge and Cloud

4.  Function Deployment Constraints

4.1.  Node Capability Constraints

   The diversity of SFs results in different requirements to
   capabilities of nodes carrying them.  For example, AI training
   applications may need powerful CPUs and large storage to handle the
   samples.  Therefore, it is not appropriate to deploy such a SF on



Liu, et al.              Expires April 24, 2019                 [Page 6]

Internet-Draft      SFC in Industrial Edge Computing        October 2018


   gateways or end devices with contrained resources.  Besides, some
   ECNs may have expertise for certain SFs, therefore it will be more
   efficient to deploy such SFs on these ECNs.  For instance, it is
   better to let a ECN equipped with a GPU to conduct image processing
   function.

4.2.  Performance Constraints

   The users may have performance requirements on the SFPs or a certain
   SF, e.g., the end-to-end delay of the SFP, the response time of SFs,
   the network bandwidth that the SFs demand, etc.  A SF SHOULD be
   deployed close to the data source if it requires a short response
   time, since the round-trip to the cloud takes a long time.  Data
   compression/aggregation SHOULD be performed to avoid sending large
   amounts of data to the cloud, if the users are willing to save their
   expenditure in network rental.

4.3.  Privacy Constraints

   Privacy must be considered for industrial data.  Industrial
   professionals are not willing to expose their sensitive data to the
   public network/cloud.  Thus the data must be processed in the portion
   of the network that the industry can control, e.g. the gateway, the
   local server.  In this case, the related functions MUST be deployed
   at the edge instead of the cloud.

5.  SFC for Edge Computing use case

   In order to have an intuitive view for how to implement SFC in edge
   computing, we use connected elevator as an example.  An edge gateway
   is deployed for each elevator or a group of elevators to process the
   data from the sensors or cameras.  Compared to the raw data, the
   volume of the data to be uploaded to the cloud is greatly reduced.
   Besides, the edge gateway can react in a short timeframe when dealing
   with emergency situations due to the avoidance of a round-trip to the
   cloud.  An edge cloud server at the campus level may also be deployed
   to perform elevator management, execute commands from the cloud or
   undertake the tasks offloaded from the edge gateways.  In the cloud
   data center, more complex applications are installed, such as
   predictive maintenance, machine learning, digital twins, etc.
   Figure 2 shows the described architecture.  All the applications at
   the edge and on the cloud can be organized in the form of an SFC.
   Since then, we use the term "SF" to represent the "applications".








Liu, et al.              Expires April 24, 2019                 [Page 7]

Internet-Draft      SFC in Industrial Edge Computing        October 2018


                           +-------+            +--------+          ---
                           |Sensors|            | Camera |           ^
                           +---+---+            +----+---+           |
                               |                     |               |
                               +----------+----------+               |
                     *- ------------------|------*                   |
                     |  +---+       +-----+----+ |                   |
                     |  |SF1|+--+   |Classifier| |                   |
                     |  +---+   |   +-----+----+ |    *-----------*  |
                     |          |         |      |    |           |  |
                     | +----+   |       +-+-+    |    |   +---+   |  |
     Edge Gateway    | |SF2a|+--+-------+SFF+------------+|SF4|   |  |
                     | +----+   |       +-+-+    |    |   +---+   |  |
                     |          |         |      |    *-----------*
                     | +----+   |         |      |   Video Processor E
                     | |SF3a|+--+         |      |                   d
                     | +----+             |      |                   g
                     *- ------------------|------*                   e
                                          +-------+                  |
                        *-----------------|----*  |                  |
                        |   +----+        |    |  |                  |
                        |   |SF2b|+--+    |    |  |                  |
                        |   +----+   |  +-+-+  |  |                  |
    Edge Cloud          |            +--+SFF|  |  |                  |
   (Campus Server)      |   +----+   |  +-+-+  |  |                  |
                        |   |SF3b|+--+    |    |  |                  |
                        |   +----+        |    |  |                  |
                        *-----------------|----*  |                  v
                                          |       |                 ---
                                          +-------+                  ^
                   *----------------------|----------*               |
                   | +----+               |          |               |
                   | |SF3c|+-------+      |          |
                   | +----+        |      |          |               C
                   | +---+         |    +-+-+        |               l
                   | |SF5|+--------+---+|SFF|        |               o
     Data Center   | +---+         |    +---+        |               u
                   | +---+         |                 |               d
                   | |SF6|+--------+                 |
                   | +---+         |                 |               |
                   | +---+         |                 |               |
                   | |SF7|+--------+                 |               v
                   | +---+                           |              ---
                   *---------------------------------*

         Figure 2: An example for using SFC in connected elevator





Liu, et al.              Expires April 24, 2019                 [Page 8]

Internet-Draft      SFC in Industrial Edge Computing        October 2018


   +-----------------+----------------------+--------------------------+
   |     Service     |     Explaination     |  Deployment Constraints  |
   |    Functions    |                      |                          |
   +-----------------+----------------------+--------------------------+
   |       SF1       | Fault Determination  |       Edge Gateway       |
   |       SF2       |   Data Aggregation   | Edge Gateway/Edge Cloud  |
   |       SF3       |     Data Logging     |    Edge Gateway/Edge     |
   |                 |                      |       Cloud/Cloud        |
   |       SF4       |   Video Processing   |     Video Processor      |
   |       SF5       |      Predictive      |          Cloud           |
   |                 |     Maintenance      |                          |
   |       SF6       |     AI trainning     |          Cloud           |
   |       SF7       |        Alarm         |          Cloud           |
   +-----------------+----------------------+--------------------------+

                  Table 1: The SFs in connected elevator

                  +----------+-------------------------+
                  | Path IDs |          Paths          |
                  +----------+-------------------------+
                  |   SFP1   | SF1-->SF2a-->SF3a-->SF5 |
                  |   SFP2   | SF1-->SF2b-->SF3b-->SF5 |
                  |   SFP3   |        SF3-->SF6        |
                  |   SFP4   |        SF1-->SF7        |
                  +----------+-------------------------+

                  Table 2: The SFPs in connected elevator

   Table 1 shows a list of SFs and their deployment constraints.  SF1
   must be deployed at the edge gateway, i.e. close to the data source,
   because the elevator must react in a short timeframe when a fault is
   detected.  The SF2 data aggregation should be deployed at the edge
   (edge gateway (SF2a) or edge cloud (SF2b)), if the user is willing to
   save network bandwidth.  The aggregated data can be stored at the
   edge as a distributed database and can be pulled by the cloud when
   needed, or directly on the cloud as mass storage is provided there.
   The SF4 video processing should be handled a the dedicated processor
   to achieve maximum efficiency.  The SFs requiring strong computing
   abilities such as predictive maintenance (SF5) and AI training (SF6)
   should be deployed on the cloud.  Alarms should be triggered on the
   cloud when faults are detected at the edge, so that the maintenance
   staff can be informed.

5.1.  Building paths from chains

   In the example of connected elevator, there are three SFCs.  How to
   instantiate the SFC to actual SFPs depends on the deployment
   constraints of SFs and the requirements of users.  According to the



Liu, et al.              Expires April 24, 2019                 [Page 9]

Internet-Draft      SFC in Industrial Edge Computing        October 2018


   constraints listed in Table 1, there are 5 possible paths for the
   chain SF1-->SF2-->SF3-->SF5.  The users can decide to use some or all
   of these paths.  Some paths can be prioritized over the others
   depending on user defined objective functions, such as:

   o  Maximize the use of the edge: decentralization, deploy the SFs at
      the edge as many as possible, make full use of the computing power
      at the edge.  This objective function may be preferred by users
      pursuing timely response and data privacy.

   o  Maximize the use of the cloud: centralization, deploy the SFs on
      the cloud as many as possible, so that the edge focuses only on
      the necessary SFs like timely response tasks.  This objective
      function may be preferred by users that don't have powerful edge
      computing devices.

   o  Minimize the traffic between the edge and the cloud: deploy the
      SFs and SFFs which have relatively large communication traffic at
      the same place.

   In actual deployment, first the users must identify the constraints
   on which they have concerns.  Then the users must find out the paths
   which meet these constraints, after that order all the possible paths
   according to the objective function.  The users may choose one
   primary path (e.g.  SF1-->SF2a-->SF3a-->SF5), and several paths as
   backups, e.g.  SF1-->SF2b-->SF3b-->SF5 and SF1-->SF2b-->SF3c-->SF5.

5.2.  Selecting a path

   The Classifier is in charge of filtering the flows which should enter
   the SFC and deciding which path to follow.  The classification is
   conducted by user-defined policies, such as source/destination port,
   IP addresses.  The initial classification happens at the ingress of
   the SFC domain.  In the case of edge computing, it can be the edge
   gateway.  Related information can be found in the section 4.7 of
   [RFC7665].

   Besides, attaching the traffic to a specific SFP can also depends on
   the status of the paths.  For example, if the primary path is fully
   loaded, the classifier should direct the subsequent traffic to one of
   the backup paths.  The status of a path can be acquired by iOAM
   [I-D.brockners-sfc-ioam-nsh] using the trace options.  Then the
   egress of the SFC domain will upload the status to the controller.
   And the controller will affect the initial classification
   accordingly.






Liu, et al.              Expires April 24, 2019                [Page 10]

Internet-Draft      SFC in Industrial Edge Computing        October 2018


5.3.  Path redirection

   As introduced in [RFC7665], a SFP can be redirected to another SFP.
   For example, in Figure 2, a flow is originally directed to SFP1,
   however, a fault is detected thus it must be redirected to SFP4 to
   trigger the alarm (SF7).  The redirection can be done by assigning
   another path ID in the NSH header.

6.  Applicability Requirements

   The following requirements should be considered when using SFC to
   organize the applications across the edge and the cloud in industrial
   IoT:

   o  The SFs MUST be deployed at qualified places regarding to the
      deployment constraints.

   o  Objective functions SHOULD be defined to sort all the possible
      SFPs, so that the users can find out the optimal path.

   o  It is RECOMMENDED to build backup paths.  When demanded
      performance is not achieved, the primary path SHOULD be switched
      to a backup path.

   o  An orchestrator or controller MAY be required to build the path
      and detect the status of the path, the SFs and SFFs.
      Configuration, management interface.

   o  A control plane is needed to update the forwarding tables
      accordingly in the network when a SFP is changed.

   o  Coordination between controllers

7.  IANA Considerations

   This memo includes no request to IANA.

8.  Security Considerations

   TBD

9.  References

9.1.  Normative References







Liu, et al.              Expires April 24, 2019                [Page 11]

Internet-Draft      SFC in Industrial Edge Computing        October 2018


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

   [RFC7665]  Halpern, J., Ed. and C. Pignataro, Ed., "Service Function
              Chaining (SFC) Architecture", RFC 7665,
              DOI 10.17487/RFC7665, October 2015,
              <https://www.rfc-editor.org/info/rfc7665>.

9.2.  Informative References

   [I-D.brockners-sfc-ioam-nsh]
              Brockners, F., Bhandari, S., Govindan, V., Pignataro, C.,
              Gredler, H., Leddy, J., Youell, S., Mizrahi, T., Mozes,
              D., Lapukhov, P., and R. Chang, "NSH Encapsulation for In-
              situ OAM Data", draft-brockners-sfc-ioam-nsh-01 (work in
              progress), March 2018.

   [I-D.geng-iiot-edge-computing-problem-statement]
              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.

   [I-D.zhang-iiot-edge-computing-gap-analysis]
              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.

Authors' Addresses

   Bing Liu
   Huawei Technologies
   No. 156 Beiqing Rd. Haidian District
   Beijing  100095
   China

   Email: remy.liubing@huawei.com











Liu, et al.              Expires April 24, 2019                [Page 12]

Internet-Draft      SFC in Industrial Edge Computing        October 2018


   Konstantinos Katsalis
   Huawei Technologies
   No. 12 Riesstrasse
   Munich  80992
   Germany

   Email: kostas.katsalis@huawei.com


   Mingui Zhang
   Huawei Technologies
   No. 156 Beiqing Rd. Haidian District
   Beijing  100095
   China

   Email: zhangmingui@huawei.com



































Liu, et al.              Expires April 24, 2019                [Page 13]