idnits 2.17.1 draft-liu-iiot-sfc-edge-computing-applicability-00.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 21, 2018) is 2007 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Industrial Internet of Things B. Liu 3 Internet-Draft K. Katsalis 4 Intended status: Informational M. Zhang 5 Expires: April 24, 2019 Huawei Technologies 6 October 21, 2018 8 Service Function Chaining Applicability in Industrial Edge Computing 9 draft-liu-iiot-sfc-edge-computing-applicability-00 11 Abstract 13 Decoupling functions from the industrial hardware enables diverse, 14 migratable, cross-industry replicable applications to be deployed 15 with flexibility at the edge and on the cloud. Users should be free 16 to adjust their business policies in industrial IoT and with low 17 cost. Therefore efficient and dynamic orchestration of the 18 applications is critical. This document describes several use cases 19 that demonstrate the applicability of Service Function Chaining in 20 industrial edge computing to organize the applications and provides 21 extra requirements to support this applicability. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on April 24, 2019. 40 Copyright Notice 42 Copyright (c) 2018 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Industrial Edge Computing Overview . . . . . . . . . . . . . 4 60 4. Function Deployment Constraints . . . . . . . . . . . . . . . 6 61 4.1. Node Capability Constraints . . . . . . . . . . . . . . . 6 62 4.2. Performance Constraints . . . . . . . . . . . . . . . . . 7 63 4.3. Privacy Constraints . . . . . . . . . . . . . . . . . . . 7 64 5. SFC for Edge Computing use case . . . . . . . . . . . . . . . 7 65 5.1. Building paths from chains . . . . . . . . . . . . . . . 9 66 5.2. Selecting a path . . . . . . . . . . . . . . . . . . . . 10 67 5.3. Path redirection . . . . . . . . . . . . . . . . . . . . 11 68 6. Applicability Requirements . . . . . . . . . . . . . . . . . 11 69 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 70 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 71 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 72 9.1. Normative References . . . . . . . . . . . . . . . . . . 11 73 9.2. Informative References . . . . . . . . . . . . . . . . . 12 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 76 1. Introduction 78 Cloudification has become a consensus trend in many domains due to 79 the low cost, high scalability and reliability of the cloud. 80 However, cloudification may not be easy or applicable for all aspects 81 of industrial internet of things. In order to achieve control 82 stability, an input must be given to the system with a bounded 83 latency. For example, the control loop of a robotic arm can be 10ms, 84 in which time the system must acquire the sensors' signals, compute 85 the input and send it to the actuators. Deploying the controller 86 remotely on the cloud is not practical because the round trip of 87 signals is too time consuming, and packet loss will lead to 88 instability. Besides, transmitting all the raw data to the cloud is 89 not economical: VPNs or reserved bandwidth needs much more 90 expenditure. In addition, industrial data is so sensitive that the 91 owners of the data are not willing to expose it on the public 92 Internet. Sending the raw data to the cloud presents such a risk. 94 The concept of edge computing, i.e. providing networking, compute and 95 storage capabilities close to the data source, is promising to deal 96 with the aforementioned requirements. Time sensitive applications 97 are deployed at the edge to achieve fast response. The raw data is 98 processed, filtered, or compressed, hence the size could be reduced 99 and the privacy data stays under control of users. A more detailed 100 introduction to edge computing can be found in 101 [I-D.zhang-iiot-edge-computing-gap-analysis] and 102 [I-D.geng-iiot-edge-computing-problem-statement]. 104 Tomorrow will be the era of edge cloud orchestration, where the edge 105 computing and cloud computing work together to meet the various 106 requirements of users. Diverse applications will be deployed at the 107 edge and on the cloud. How to deploy them correctly to realize the 108 industry users' policies, and how to manage the applications 109 efficiently when the policy changes, are currently open questions. 110 Since the edge is the ingress of data, when the data from different 111 sensors arrive at the edge computing device, the set of applications 112 that the data will go through should be indicated according to the 113 preset policies. After the processing by an application, the output 114 data must be forwarded to the correct next hop. Except the 115 applications which have to be deployed at the edge or the cloud due 116 to response time and processing resource requirements, multiple 117 copies of applications can be deployed at different locations, which 118 permit the offload of the tasks to other copies of the application 119 when one copy is busy or over utilized. 121 Service Function Chaining could be a suitable way to organize the 122 edge and cloud applications. The architecture in [RFC7665] realizes 123 the decoupling of the service plane and forwarding plane, making it 124 easier to add or delete one application or adjust the order of their 125 invocation. In the data plane, the NSH header helps enhance the 126 logical connection between the applications. The classifier in SFC, 127 which decides the path to forward traffic through, matches the 128 requirement of task indication. For the same SFC, different paths 129 can be deployed as backups to each other. When one path is disrupted 130 or fully loaded, the work can be offloaded to another path yet have 131 the same set of functions applied to it. 133 This document describes the idea of using SFC in industrial edge 134 computing to organize the applications according to user defined 135 policies. Use cases are given as examples to help explain the idea. 137 2. Terminology 139 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 140 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 141 document are to be interpreted as described in RFC 2119 [RFC2119]. 143 ECN 144 Edge Computing Node: An abstract appellation of devices with edge 145 computing capabilities. In industrial domain, an edge computing 146 device can be a logic controller, a gateway, or a local server 147 cluster, etc. An edge computing node MAY act as the physical 148 carrier of classifier, SFs and/or SFFs. 150 Service Function Chain 151 A service function chain defines an ordered set of abstract 152 service functions and ordering constraints that must be applied to 153 packets and/or frames and/or flows selected as a result of 154 classification. 156 Service Function 157 An SF in SFC can be mapped to an application in edge computing. 159 3. Industrial Edge Computing Overview 161 Industrial edge computing can be deployed in a hierarchical way. For 162 example, in manufacturing industry, the scope of group can refer to a 163 pipeline, and the scope of campus can refer to a factory. The data 164 comes from the end devices, such as sensors, actuators, equipment, 165 assets, etc. The end devices can be edge computing capable or 166 incapable. A group of end devices (e.g. geographical neighbors) are 167 connected to an edge gateway. The edge gateway offers connectivity 168 to the wide area network and may offer connectivity among the end 169 devices. Normally, the resources on an edge gateway are constrained, 170 hence the gateway can only handle relatively simple, deterministic or 171 dedicated tasks: 173 o Local data processing: aggregation, filtering, translation, 174 consolidation and analytics. 176 o Local control/reasoning logic: automation control, decision- 177 making, fault detection, and so on. The parameters/models are 178 optimized/trained on the cloud, then assigned to the edge. 180 o Device management: edge gateway acts as the local assets manager 181 and enables remote assets management via the wide area network. 183 At the campus level, an edge cloud server with more resources may be 184 deployed. Since more resources are provided, relatively complex 185 tasks can be handled, such as: 187 o Operation management: translating upper layer abstract commands 188 into operational commands of end devices, updating parameters, 189 organizing new work flows, etc. 191 o Data desensitization: users are not willing to expose their 192 sensitive data to the public Internet, thus before uploading the 193 sensitive data must be fuzzified. 195 o Data logging: the edge cloud server may have larger storage, hence 196 it is preferred to perform the data logging at the server, 197 especially when the data is large or needs to be stored for long 198 time. 200 o Task offloading: when the edge gateway is over loaded, some tasks 201 originally being conducted at the gateways can be transferred to 202 the edge cloud if possible. 204 The campus network is connected to the cloud via an overlay private 205 network over the public network. The cloud can be private/public 206 which implements the company's or third-party regulatory authority's 207 applications. The applications deployed on the cloud are usually 208 computationally intensive and require mass storage. These 209 applications involve big data analysis, MES, ERP, CRM, etc. 211 It should be clarified that the aforementioned applications and the 212 hierarchy to deploy them are just examples. The actual deployment 213 depends on the use cases and requirements. 215 +------------------+ 216 | | 217 | Cloud | 218 | | 219 +---------+--------+ 220 | 221 | .................. 222 _,..+.._ .Campus 2 . 223 ,-' `-. .+--------------+. 224 / `. .| |. 225 | Network |+-----------+ Edge Cloud |. 226 `. / .| |. 227 `.__ __,-' .+--------------+. 228 `''+' .................. 229 ...............................|........................ 230 .Campus 1 | . 231 . +-------+------+ . 232 . | | . 233 . | Edge Cloud | . 234 . | | . 235 . +-------+------+ . 236 . | . 237 . +--------------+---------------+ . 238 . | | . 239 .*--------------|--------------* *-------|------*. 240 .| +------+-----+ | |+------+-----+|. 241 .| |Edge Gateway| | ||Edge Gateway||. 242 .| +------+-----+ | |+------+-----+|. 243 .| | | | | |. 244 .| +-------+-------+ | | | |. 245 .| | | | | | |. 246 .|+-----+----+ +-----+----+ | | +-----+----+ |. 247 .||End Device| |End Device| | | |End Device| |. 248 .|+----------+ +----------+ | | +----------+ |. 249 .| Group 1 | | Group 2 |. 250 .*-----------------------------* *--------------*. 251 ........................................................ 253 Figure 1: Hierarchical Deployment of Edge and Cloud 255 4. Function Deployment Constraints 257 4.1. Node Capability Constraints 259 The diversity of SFs results in different requirements to 260 capabilities of nodes carrying them. For example, AI training 261 applications may need powerful CPUs and large storage to handle the 262 samples. Therefore, it is not appropriate to deploy such a SF on 263 gateways or end devices with contrained resources. Besides, some 264 ECNs may have expertise for certain SFs, therefore it will be more 265 efficient to deploy such SFs on these ECNs. For instance, it is 266 better to let a ECN equipped with a GPU to conduct image processing 267 function. 269 4.2. Performance Constraints 271 The users may have performance requirements on the SFPs or a certain 272 SF, e.g., the end-to-end delay of the SFP, the response time of SFs, 273 the network bandwidth that the SFs demand, etc. A SF SHOULD be 274 deployed close to the data source if it requires a short response 275 time, since the round-trip to the cloud takes a long time. Data 276 compression/aggregation SHOULD be performed to avoid sending large 277 amounts of data to the cloud, if the users are willing to save their 278 expenditure in network rental. 280 4.3. Privacy Constraints 282 Privacy must be considered for industrial data. Industrial 283 professionals are not willing to expose their sensitive data to the 284 public network/cloud. Thus the data must be processed in the portion 285 of the network that the industry can control, e.g. the gateway, the 286 local server. In this case, the related functions MUST be deployed 287 at the edge instead of the cloud. 289 5. SFC for Edge Computing use case 291 In order to have an intuitive view for how to implement SFC in edge 292 computing, we use connected elevator as an example. An edge gateway 293 is deployed for each elevator or a group of elevators to process the 294 data from the sensors or cameras. Compared to the raw data, the 295 volume of the data to be uploaded to the cloud is greatly reduced. 296 Besides, the edge gateway can react in a short timeframe when dealing 297 with emergency situations due to the avoidance of a round-trip to the 298 cloud. An edge cloud server at the campus level may also be deployed 299 to perform elevator management, execute commands from the cloud or 300 undertake the tasks offloaded from the edge gateways. In the cloud 301 data center, more complex applications are installed, such as 302 predictive maintenance, machine learning, digital twins, etc. 303 Figure 2 shows the described architecture. All the applications at 304 the edge and on the cloud can be organized in the form of an SFC. 305 Since then, we use the term "SF" to represent the "applications". 307 +-------+ +--------+ --- 308 |Sensors| | Camera | ^ 309 +---+---+ +----+---+ | 310 | | | 311 +----------+----------+ | 312 *- ------------------|------* | 313 | +---+ +-----+----+ | | 314 | |SF1|+--+ |Classifier| | | 315 | +---+ | +-----+----+ | *-----------* | 316 | | | | | | | 317 | +----+ | +-+-+ | | +---+ | | 318 Edge Gateway | |SF2a|+--+-------+SFF+------------+|SF4| | | 319 | +----+ | +-+-+ | | +---+ | | 320 | | | | *-----------* 321 | +----+ | | | Video Processor E 322 | |SF3a|+--+ | | d 323 | +----+ | | g 324 *- ------------------|------* e 325 +-------+ | 326 *-----------------|----* | | 327 | +----+ | | | | 328 | |SF2b|+--+ | | | | 329 | +----+ | +-+-+ | | | 330 Edge Cloud | +--+SFF| | | | 331 (Campus Server) | +----+ | +-+-+ | | | 332 | |SF3b|+--+ | | | | 333 | +----+ | | | | 334 *-----------------|----* | v 335 | | --- 336 +-------+ ^ 337 *----------------------|----------* | 338 | +----+ | | | 339 | |SF3c|+-------+ | | 340 | +----+ | | | C 341 | +---+ | +-+-+ | l 342 | |SF5|+--------+---+|SFF| | o 343 Data Center | +---+ | +---+ | u 344 | +---+ | | d 345 | |SF6|+--------+ | 346 | +---+ | | | 347 | +---+ | | | 348 | |SF7|+--------+ | v 349 | +---+ | --- 350 *---------------------------------* 352 Figure 2: An example for using SFC in connected elevator 354 +-----------------+----------------------+--------------------------+ 355 | Service | Explaination | Deployment Constraints | 356 | Functions | | | 357 +-----------------+----------------------+--------------------------+ 358 | SF1 | Fault Determination | Edge Gateway | 359 | SF2 | Data Aggregation | Edge Gateway/Edge Cloud | 360 | SF3 | Data Logging | Edge Gateway/Edge | 361 | | | Cloud/Cloud | 362 | SF4 | Video Processing | Video Processor | 363 | SF5 | Predictive | Cloud | 364 | | Maintenance | | 365 | SF6 | AI trainning | Cloud | 366 | SF7 | Alarm | Cloud | 367 +-----------------+----------------------+--------------------------+ 369 Table 1: The SFs in connected elevator 371 +----------+-------------------------+ 372 | Path IDs | Paths | 373 +----------+-------------------------+ 374 | SFP1 | SF1-->SF2a-->SF3a-->SF5 | 375 | SFP2 | SF1-->SF2b-->SF3b-->SF5 | 376 | SFP3 | SF3-->SF6 | 377 | SFP4 | SF1-->SF7 | 378 +----------+-------------------------+ 380 Table 2: The SFPs in connected elevator 382 Table 1 shows a list of SFs and their deployment constraints. SF1 383 must be deployed at the edge gateway, i.e. close to the data source, 384 because the elevator must react in a short timeframe when a fault is 385 detected. The SF2 data aggregation should be deployed at the edge 386 (edge gateway (SF2a) or edge cloud (SF2b)), if the user is willing to 387 save network bandwidth. The aggregated data can be stored at the 388 edge as a distributed database and can be pulled by the cloud when 389 needed, or directly on the cloud as mass storage is provided there. 390 The SF4 video processing should be handled a the dedicated processor 391 to achieve maximum efficiency. The SFs requiring strong computing 392 abilities such as predictive maintenance (SF5) and AI training (SF6) 393 should be deployed on the cloud. Alarms should be triggered on the 394 cloud when faults are detected at the edge, so that the maintenance 395 staff can be informed. 397 5.1. Building paths from chains 399 In the example of connected elevator, there are three SFCs. How to 400 instantiate the SFC to actual SFPs depends on the deployment 401 constraints of SFs and the requirements of users. According to the 402 constraints listed in Table 1, there are 5 possible paths for the 403 chain SF1-->SF2-->SF3-->SF5. The users can decide to use some or all 404 of these paths. Some paths can be prioritized over the others 405 depending on user defined objective functions, such as: 407 o Maximize the use of the edge: decentralization, deploy the SFs at 408 the edge as many as possible, make full use of the computing power 409 at the edge. This objective function may be preferred by users 410 pursuing timely response and data privacy. 412 o Maximize the use of the cloud: centralization, deploy the SFs on 413 the cloud as many as possible, so that the edge focuses only on 414 the necessary SFs like timely response tasks. This objective 415 function may be preferred by users that don't have powerful edge 416 computing devices. 418 o Minimize the traffic between the edge and the cloud: deploy the 419 SFs and SFFs which have relatively large communication traffic at 420 the same place. 422 In actual deployment, first the users must identify the constraints 423 on which they have concerns. Then the users must find out the paths 424 which meet these constraints, after that order all the possible paths 425 according to the objective function. The users may choose one 426 primary path (e.g. SF1-->SF2a-->SF3a-->SF5), and several paths as 427 backups, e.g. SF1-->SF2b-->SF3b-->SF5 and SF1-->SF2b-->SF3c-->SF5. 429 5.2. Selecting a path 431 The Classifier is in charge of filtering the flows which should enter 432 the SFC and deciding which path to follow. The classification is 433 conducted by user-defined policies, such as source/destination port, 434 IP addresses. The initial classification happens at the ingress of 435 the SFC domain. In the case of edge computing, it can be the edge 436 gateway. Related information can be found in the section 4.7 of 437 [RFC7665]. 439 Besides, attaching the traffic to a specific SFP can also depends on 440 the status of the paths. For example, if the primary path is fully 441 loaded, the classifier should direct the subsequent traffic to one of 442 the backup paths. The status of a path can be acquired by iOAM 443 [I-D.brockners-sfc-ioam-nsh] using the trace options. Then the 444 egress of the SFC domain will upload the status to the controller. 445 And the controller will affect the initial classification 446 accordingly. 448 5.3. Path redirection 450 As introduced in [RFC7665], a SFP can be redirected to another SFP. 451 For example, in Figure 2, a flow is originally directed to SFP1, 452 however, a fault is detected thus it must be redirected to SFP4 to 453 trigger the alarm (SF7). The redirection can be done by assigning 454 another path ID in the NSH header. 456 6. Applicability Requirements 458 The following requirements should be considered when using SFC to 459 organize the applications across the edge and the cloud in industrial 460 IoT: 462 o The SFs MUST be deployed at qualified places regarding to the 463 deployment constraints. 465 o Objective functions SHOULD be defined to sort all the possible 466 SFPs, so that the users can find out the optimal path. 468 o It is RECOMMENDED to build backup paths. When demanded 469 performance is not achieved, the primary path SHOULD be switched 470 to a backup path. 472 o An orchestrator or controller MAY be required to build the path 473 and detect the status of the path, the SFs and SFFs. 474 Configuration, management interface. 476 o A control plane is needed to update the forwarding tables 477 accordingly in the network when a SFP is changed. 479 o Coordination between controllers 481 7. IANA Considerations 483 This memo includes no request to IANA. 485 8. Security Considerations 487 TBD 489 9. References 491 9.1. Normative References 493 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 494 Requirement Levels", BCP 14, RFC 2119, 495 DOI 10.17487/RFC2119, March 1997, 496 . 498 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 499 Chaining (SFC) Architecture", RFC 7665, 500 DOI 10.17487/RFC7665, October 2015, 501 . 503 9.2. Informative References 505 [I-D.brockners-sfc-ioam-nsh] 506 Brockners, F., Bhandari, S., Govindan, V., Pignataro, C., 507 Gredler, H., Leddy, J., Youell, S., Mizrahi, T., Mozes, 508 D., Lapukhov, P., and R. Chang, "NSH Encapsulation for In- 509 situ OAM Data", draft-brockners-sfc-ioam-nsh-01 (work in 510 progress), March 2018. 512 [I-D.geng-iiot-edge-computing-problem-statement] 513 Geng, L., Zhang, M., McBride, M., and B. Liu, "Problem 514 Statement of Edge Computing on Premises for Industrial 515 IoT", draft-geng-iiot-edge-computing-problem-statement-01 516 (work in progress), March 2018. 518 [I-D.zhang-iiot-edge-computing-gap-analysis] 519 Zhang, M., Liu, B., McBride, M., Hu, C., and L. Geng, "Gap 520 Analysis of Edge Computing for Industrial IoT", draft- 521 zhang-iiot-edge-computing-gap-analysis-00 (work in 522 progress), March 2018. 524 Authors' Addresses 526 Bing Liu 527 Huawei Technologies 528 No. 156 Beiqing Rd. Haidian District 529 Beijing 100095 530 China 532 Email: remy.liubing@huawei.com 533 Konstantinos Katsalis 534 Huawei Technologies 535 No. 12 Riesstrasse 536 Munich 80992 537 Germany 539 Email: kostas.katsalis@huawei.com 541 Mingui Zhang 542 Huawei Technologies 543 No. 156 Beiqing Rd. Haidian District 544 Beijing 100095 545 China 547 Email: zhangmingui@huawei.com