idnits 2.17.1 draft-zhang-iiot-edge-computing-gap-analysis-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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (March 5, 2018) is 2237 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC2119' is defined on line 395, but no explicit reference was found in the text == Unused Reference: 'I-D.geng-iiot-edge-computing-problem-statement' is defined on line 402, but no explicit reference was found in the text == Outdated reference: A later version (-01) exists of draft-geng-iiot-edge-computing-problem-statement-00 == Outdated reference: A later version (-16) exists of draft-ietf-nvo3-vmm-01 Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IIoT M. Zhang 3 Internet-Draft B. Liu 4 Intended status: Standards Track Huawei Technologies 5 Expires: September 6, 2018 M. McBride 6 Futurewei 7 C. Hu 8 Xilinx 9 L. Geng 10 China Mobile 11 March 5, 2018 13 Gap Analysis of Edge Computing for Industrial IoT 14 draft-zhang-iiot-edge-computing-gap-analysis-00 16 Abstract 18 This document investigates the requirements of Edge Computing in the 19 Industrial Internet of Things(IIOT) domain and identifies 10 20 standardization gaps within 5 key requirements. The related works 21 inside the IETF are also evaluated. 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 September 6, 2018. 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. Inter-operability of the Industrial Internet . . . . . . . . 3 59 2.1. Gateway between two Industrial Networks . . . . . . . . . 3 60 2.2. Overlay for the Industrial Internet . . . . . . . . . . . 4 61 3. Configuration and Management . . . . . . . . . . . . . . . . 5 62 3.1. Central Configuration . . . . . . . . . . . . . . . . . . 5 63 3.2. Firmware Update . . . . . . . . . . . . . . . . . . . . . 5 64 3.3. Naming and Addressing . . . . . . . . . . . . . . . . . . 5 65 4. Mobility and Migration . . . . . . . . . . . . . . . . . . . 6 66 5. South bound Communication . . . . . . . . . . . . . . . . . . 6 67 6. Orchestration between the Edge and the Cloud . . . . . . . . 7 68 7. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 69 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 70 9. Security Considerations . . . . . . . . . . . . . . . . . . . 9 71 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 72 10.1. Normative References . . . . . . . . . . . . . . . . . . 10 73 10.2. Informative References . . . . . . . . . . . . . . . . . 10 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 76 1. Introduction 78 Implementing intelligence only in the Cloud cannot fulfill all of the 79 requirements of industrial IoT. The Cloud will not always provide 80 the needed response within bounded latency requirements. Low latency 81 requirements are often critical for applications such as automatic 82 control, video surveillance/delivery, power distribution. and fault 83 alarm. The massive number of assets connected to the Cloud require a 84 large amount of bandwidth to transmit the raw data, and the Cloud 85 needs large computation and storage resources to handle this high 86 volume of data. The raw data often contains sensitive information 87 and the leakage of this data from the Cloud may cause harm to the the 88 business. Most industrial environments don't want to put all the 89 data in one place, ie, the Cloud. Distributed Edge Computing is 90 proposed to deal with these industrial requirements. 92 Edge computing is a distributed open platform at the network edge, 93 close to the things or data sources, integrating the capabilities of 94 networks, storage, and applications. By delivering edge intelligence 95 services, edge computing meets the key requirements of industry 96 digitalization for agile connectivity, real-time services, data 97 optimization, application intelligence, security and privacy 98 protection. 100 Various organizations are working on the industrialization of Edge 101 Computing. In 2017, ISO/IEC JTC 1/SC41 established the edge 102 computing research group to promote the standardization of Edge 103 Computing. In 2016, the Edge Computing Consortium (ECC) was set up 104 to work on the commercial implementation in different industrial 105 verticals. In 2017, the edge computing task group was established 106 inside the Industrial Internet Consortium (IIC) to work on the 107 reference architecture of edge computing. 109 Local, low latency computation, storage and communication are the 110 three main aspects of Edge Computing. Communication is the key to 111 enable data flow between assets, from assets to gateway, between 112 gateways at the edge, from the gateway to the Cloud, etc., which all 113 fall naturally into the scope of IETF. 115 This document identifies the requirements of Edge Computing in the 116 industrial domain, and investigates the related standardization gaps 117 for each requirement. Its the intention of this draft to identify 118 the gaps which may need to be addressed within the IETF 120 2. Inter-operability of the Industrial Internet 122 According to a 2015 survey by IoT Nexus, 77% of professionals 123 surveyed believe that interoperability is the largest challenge 124 facing the Industrial Internet. Different industrial branches such 125 as product lines, factories and logistics will need to interact 126 closely with each other or even merge. And legacy machines will 127 continue to exist until the factory is fully upgraded. The 128 interoperability between legacy and upgraded equipment will need to 129 become commonplace. 131 2.1. Gateway between two Industrial Networks 133 Currently, there are more than 40 fieldbus technologies being used in 134 the industrial domain, such as Profibus, CANopen, Modbus, providing 135 low cost digital industrial connection. However, their data rates 136 are limited, and the hardware integration is complicated. Industrial 137 Ethernet, like PROFINET, SECOSI, EtherCAT and POWERLINK, can provide 138 a unified hardware interface, higher data rate and reusable Internet 139 protocols. But the incompatibility between different technologies is 140 still unresolved, which makes one local network unable to communicate 141 with another if they speak different machine languages. When 142 manufacturers want to extend their product line, they need to 143 purchase equipment which speaks a specific language, which leads to 144 vendor locked-in. Equipment which is using legacy fieldbus 145 technologies will need to be abandoned when the manufacturers want to 146 upgrade their network. 148 In order to enable the direct communication between two subnets which 149 speak different languages or to realize backward compatibility, 150 protocol translation is indispensable. Edge computing nodes will 151 serve as the gateway between two industrial networks and will be an 152 ideal place to implement this translation function. Therefore, one 153 identified gap is to define the mapping between any two machine 154 languages that are considered to be popular. It is suggested that 155 SDOs (such as the IETF) or commercial consortiums related to 156 operational technologies, will provide a solution to this item. 158 2.2. Overlay for the Industrial Internet 160 Usually the processing plants, workshops or factory locations of a 161 specific manufacturer have their own unique products within various 162 industrial verticals, and the control logic is locally closed to 163 achieve high reliability and robustness. The data is also kept in 164 local networks and cannot be used by the others, creating information 165 silos. Next generation manufacturing requires close interaction of 166 different branches to achieve flexibility, optimality and efficiency. 167 For example, two parallel assembly lines can synchronize their paces 168 via interconnection; when one processing section sends out alarms, 169 the other sections will be informed and react proactively. The robot 170 in the logistics network, for example, can transport various 171 materials to the production network within the necessary response 172 time. 174 The industrial networks speak different physical languages. 175 Therefore, an overlay is required to achieve the interconnection 176 between multiple networks. Different machine languages are 177 translated into a common protocol used as the overlay. The edge 178 computing nodes can realize the protocol conversion at the ingress of 179 the overlay and act as routers in the overlay network. For small or 180 medium scale, e.g. inside a workshop or a factory, the overlay can be 181 done by TSN tunnelling or thru a dedicated fiber-optic channel. For 182 large scale, e.g. two factories in two cities, L2VPN/L3VPN on public 183 network can be used. If time sensitive applications are carried, the 184 bonded-latency requirement should be added. 186 Industrial IoT systems are both delay sensitive and loss sensitive, 187 which rely on very robust and predictable network connections. The 188 overlay must meet these requirements. The recent paradigm in 189 transportation layer congestion control to avoid loss and provide 190 short delay still has a long tail for the perform, which does not 191 meet the requirement of Industrial IoT. The traditional industrial 192 systems use redundancy to guarantee the high availability for 193 networks on critical infrastructure (HSR: High-availability Seamless 194 Redundancy, PRP: Parallel Redundancy Protocol), which is a high cost 195 solution and faces the interoperability problem among different 196 systems. IEEE 802.1 defined the TSN (time-sensitive- network) 197 technical standards, aiming to promote standardization and 198 interoperability of real-time Ethernet networks, so that data flows 199 demanding bounded latency and best effort data flows can be 200 transmitted in one single network. Inside IETF, the DETNET working 201 group is working on an L3 overall architecture for deterministic 202 networking. It is promising to have foo-over-DETNET/TSN in the 203 future. Therefore a gap may or may not exist to provide a solution 204 to this protocol conversion overlay. 206 3. Configuration and Management 208 3.1. Central Configuration 210 The network SHOULD be configured before the industrial operation. 211 And the configuration can also be changed during the operation to 212 better meet the requirements. The configuration MAY include Node_ID, 213 connectivity between nodes, the network topology, the end to end 214 paths and their bandwidth and latency requirements. The connectivity 215 between nodes can be configured by Pub/Sub pattern, in which the 216 senders publish the messages in different classes, and the receivers 217 subscribe to the classes they are interested in. The publishers 218 don't have knowledge about the subscriber, and vice versa. 220 The configuration can be done in a centralized way via Netconf and 221 YANG model. The information model of different verticals to describe 222 the data type in YANG should be unified, so that a data in one 223 vertical can be recognized by another verticals. 225 3.2. Firmware Update 227 The firmware of devices needs to be updated on-demand to deal with 228 security vulnerabilities, to update the installed applications or to 229 install new ones. The update can be conducted via HTTP or FTP. 230 However, how to update the firmware for constrained devices in a more 231 secure and efficient way is still an open issue. The SUIT (BOF) is 232 aiming to work on the related solutions. 234 3.3. Naming and Addressing 236 Given massive amount of heterogeneous devices deployed across 237 different Industrial IoT platforms, naming and addressing play as a 238 key role to coordinate the back-end data center, edge and end 239 devices, e.g., the efficient upstream sensory data collection, 240 content-based data filtering and matching, and downstream efficient 241 control by applications. 243 Currently used schemes like IP and URI are experiencing some big 244 challenges, which are not efficient in the context of Industrial IoT. 245 The changes in date centers/edge/end devices should be transparent to 246 others and the changes including but not limited to the migration of 247 the service (like storage, database) in date centers/edge, the update 248 of the program in end devices and so on. 250 IPv6 is expected to be the base of IoT in the future and its lack of 251 mobility and security inherently has been extending for a while. It 252 is a very essential requirement for the computing purpose that the 253 naming and addressing could be far more flexible, agile and secure 254 than what we could provide today. Besides IP related solutions, some 255 other naming schemes have been developed (e.g., Object Name Service 256 (ONS), IoT@Work naming scheme, NDN, MobilityFirst, etc.), each which 257 could have a place in some certain domains but not a cure to a 258 general IIoT naming and addressing problem. 260 4. Mobility and Migration 262 Some scenarios require mobility, e.g. when a mobile robot moves from 263 one workshop to another, it may also roam between two edge computing 264 nodes. The applications, running in the previous edge computing node 265 SHOULD migrate to the current node, so that the robot's task is 266 uninterrupted. The applications can migrate between edge computing 267 nodes with different capabilities and different hardware, e.g. 268 gateways, server clusters and all types of nodes in between. 270 The applications can be encapsulated in containers or virtual 271 machines to facilitate the migration between edge computing nodes. 272 The states in the previous ECN SHOULD be synchronized to the new ECN, 273 so that the latter can run the application continuously. Common APIs 274 SHOULD be defined for different types of ECNs to shield the 275 heterogeneity. A layer-2 network SHOULD be created to facilitate the 276 VM mobility [RFC8302] [I-D.ietf-nvo3-vmm]. New API migration 277 solutions may be needed. 279 5. South bound Communication 281 In the south bound, the edge computing node MAY connect to various 282 devices using different kinds of protocols, such as Ethernet, WiFi, 283 Bluetooth, Power Line Communication, RF, RS485, etc. Thus the ECNs 284 will be versatile protocol speakers. 286 The applications, which belong to different users, SHOULD be able to 287 operate simultaneously on the ECNs. Tenant segregation MUST be 288 implemented to ensure a user's data, configuration and 289 functionalities are not impacted by another user. TRILL may help 290 realize the segregation by logical isolation of network traffic. 291 Default TRILL configuration supports 4094 VLANs, which is enough 292 since the tenants at the edge would not be as many as those in a data 293 center. If edge cloud orchestration applies, however, tenant 294 segregation on the cloud may exceed 4094. For such case, a longer 295 label than 12-bit VLAN label should be used [RFC7172] [RFC7348]. 297 Inside the IETF, ROLL (routing protocols in LLN), 6lo (IP adaptation 298 of Bluetooth, PLC, RS485, etc.) and LPWAN (RF communication protocols 299 including LoRa, Sigfox, Wi-SUN and NB-IoT) may provide southbound 300 solutions. The 6TiSCH WG's work is promising to handle the 301 requirement of adding deterministic features in RF networks. 303 6. Orchestration between the Edge and the Cloud 305 In Edge Computing, the distribution of intelligence is hierarchical. 306 For example, in manufacturing, Edge Computing Nodes can be deployed 307 on the machine tools for process configuration and status monitoring; 308 at the pipeline level, Edge Computing Nodes can be used for product 309 flow orchestration; higher at the factory level, Edge Computing Nodes 310 takes care of the coordiantion of different pipelines. 312 The data sent out by the terminals should be processed with various 313 requirements, which hopfully can be fulfilled at different levels. 314 For example, the data in automatic control should be processed at low 315 level to guarantee the bounded latency. And some key data should be 316 stored for a long time at higher level, e.g. on the Cloud. The 317 sample data for complex deep learning algorithms should be sent to 318 higher level possesseding enough processing power. 320 The terminals can generate data with various processing requirements. 321 How to deliver the data to the right level of Edge Intelligence 322 remains a gap to be covered. A potential solution is to introduce 323 these requirements inside the packet, so an Edge Computing Node can 324 know whether to process it locally or upload it to the higher level. 325 A primary idea for this to add requirement options into the IPv6 326 header and define objective functions (OF) deployed at the Edge 327 Computing Node to make the decision. 329 +-----------------+-------+-------+-------+---+----------------+ 330 | IPv6 Header |Latency|Storage|Compute|...| Data | 331 +-----------------+-------+-------+-------+---+----------------+ 332 | | 333 | Processing Requirements | 334 | | 336 Figure 1: Processing requirements in the IPv6 header 338 Similar idea can be found in 339 [I-D.purkayastha-sfc-service-indirection], where dynamic service 340 insertion model is used to steer traffic to the requisite service 341 resources. 343 7. Summary 344 +-------------------------------+--------------------------------------+ 345 | Requirements | Gaps | 346 +-------------------------------+--------------------------------------+ 347 | |Gap 1: Mapping definition between any | 348 |Req 1: Inter-operability | two machine languages | 349 | of Industrial | | 350 | Internet |Gap 2: Overlay for the Industrial | 351 | | Internet | 352 +-------------------------------+--------------------------------------+ 353 | | | 354 |Req 2: Configuration and |Gap 3: Unified information model for | 355 | Management | all kinds of verticals | 356 | | | 357 | |Gap 4: Secure firmware update | 358 | | | 359 | |Gap 5: Flexible, agile and secure | 360 | | naming and addressing | 361 +-------------------------------+--------------------------------------+ 362 | |Gap 6: A large layer-2 network to | 363 | | facilitate the VM mobility | 364 |Req 3: Mobility and Migration | | 365 | |Gap 7: Containers and VMs to | 366 | | facilitate App mobility | 367 +-------------------------------+--------------------------------------+ 368 | |Gap 8: LPWAN technologies | 369 |Req 4: South bound | | 370 | communication |Gap 9: Add deterministic features into| 371 | | RF netwrok | 372 +-------------------------------+--------------------------------------+ 373 | | | 374 |Req 5: Orchestration between |Gap 10: Differentiated service at the | 375 | the Edge and the Cloud | Edge Computing Node | 376 | | | 377 +-------------------------------+--------------------------------------+ 379 Figure 2: Requirements and Gaps of Edge Computing in IIoT 381 8. IANA Considerations 383 N/A 385 9. Security Considerations 387 Security considerations will be a critical component of IIoT edge 388 computing particularly as intelligence is moved to the extreme 389 distributed edge. 391 10. References 393 10.1. Normative References 395 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 396 Requirement Levels", BCP 14, RFC 2119, 397 DOI 10.17487/RFC2119, March 1997, 398 . 400 10.2. Informative References 402 [I-D.geng-iiot-edge-computing-problem-statement] 403 67, 4., Zhang, M., McBride, M., and B. Liu, "Problem 404 Statement of Edge Computing beyond Access Network for 405 Industrial IoT", draft-geng-iiot-edge-computing-problem- 406 statement-00 (work in progress), October 2017. 408 [I-D.ietf-nvo3-vmm] 409 Sarikaya, B., Dunbar, L., Khasnabish, B., Herbert, T., and 410 S. Dikshit, "Virtual Machine Mobility Protocol for L2 and 411 L3 Overlay Networks", draft-ietf-nvo3-vmm-01 (work in 412 progress), October 2017. 414 [I-D.purkayastha-sfc-service-indirection] 415 Purkayastha, D., Rahman, A., Trossen, D., Despotovic, Z., 416 and R. Khalili, "Alternative Handling of Dynamic Chaining 417 and Service Indirection", draft-purkayastha-sfc-service- 418 indirection-02 (work in progress), March 2018. 420 [RFC7172] Eastlake 3rd, D., Zhang, M., Agarwal, P., Perlman, R., and 421 D. Dutt, "Transparent Interconnection of Lots of Links 422 (TRILL): Fine-Grained Labeling", RFC 7172, 423 DOI 10.17487/RFC7172, May 2014, 424 . 426 [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, 427 L., Sridhar, T., Bursell, M., and C. Wright, "Virtual 428 eXtensible Local Area Network (VXLAN): A Framework for 429 Overlaying Virtualized Layer 2 Networks over Layer 3 430 Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, 431 . 433 [RFC8302] Li, Y., Eastlake 3rd, D., Dunbar, L., Perlman, R., and M. 434 Umair, "Transparent Interconnection of Lots of Links 435 (TRILL): ARP and Neighbor Discovery (ND) Optimization", 436 RFC 8302, DOI 10.17487/RFC8302, January 2018, 437 . 439 Authors' Addresses 441 Mingui Zhang 442 Huawei Technologies 443 No. 156 Beiqing Rd. Haidian District 444 Beijing 100095 445 China 447 Email: zhangmingui@huawei.com 449 Bing Liu 450 Huawei Technologies 451 No. 156 Beiqing Rd. Haidian District 452 Beijing 100095 453 China 455 Email: remy.liubing@huawei.com 457 Mike McBride 458 Futurewei 459 2330 Central Expressway 460 Santa Clara 95055 461 Unites States 463 Email: michael.mcbride@huawei.com 465 Chengchen Hu 466 Xilinx 467 5 Changi Business Park Vista Singapore 468 Singapore 486040 469 Singapore 471 Email: CHENGCHE@xilinx.com 473 Liang Geng 474 China Mobile 475 32 Xuanwumen West Street 476 Beijing, Xicheng District 100053 477 China 479 Email: gengliang@chinamobile.com