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, . [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function Chaining (SFC) Architecture", RFC 7665, DOI 10.17487/RFC7665, October 2015, . 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]