idnits 2.17.1 draft-geng-iiot-edge-computing-problem-statement-01.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 (March 5, 2018) is 2243 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) == Missing Reference: 'RFC' is mentioned on line 350, but not defined Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 T2TRG L. Geng 3 Internet-Draft China Mobile 4 Intended status: Standards Track M. Zhang 5 Expires: September 6, 2018 M. McBride 6 B. Liu 7 Huawei 8 March 5, 2018 10 Problem Statement of Edge Computing on Premises for Industrial IoT 11 draft-geng-iiot-edge-computing-problem-statement-01 13 Abstract 15 This document introduces the concept of Beyond Edge Computing (BEC) 16 which brings edge computing capabilities down to the level of 17 customers' premises for industrial IoT use cases. The purpose of the 18 document is to discuss the general problem statement of BEC including 19 capabilities, and use cases. Potential technical gaps in IETF 20 problem scope that are related to BEC are also evaluated. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on September 6, 2018. 39 Copyright Notice 41 Copyright (c) 2018 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 58 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. The Concept and Capabilities of Beyond Edge Computing . . . . 3 60 2.1. Heterogeneous IoT Device Compatibility . . . . . . . . . 4 61 2.2. Deterministic Networking . . . . . . . . . . . . . . . . 5 62 2.3. Management of Massive Amount of Devices . . . . . . . . . 5 63 2.4. Support of Network Slicing . . . . . . . . . . . . . . . 5 64 2.5. Multi-ecosystem Environment . . . . . . . . . . . . . . . 5 65 3. Reference Architecture . . . . . . . . . . . . . . . . . . . 5 66 4. Use Cases of BEC . . . . . . . . . . . . . . . . . . . . . . 7 67 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 68 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 69 7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 10 70 8. Normative References . . . . . . . . . . . . . . . . . . . . 10 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 73 1. Introduction 75 Edge computing is an important network architecture particularly in 76 the support of Industrial verticals such as Energy, Manufacturing, 77 Healthcare, Mining and Smart City/Buildings. Edge computing will 78 provide local compute, storage and connectivity services particularly 79 for latency and bandwidth sensitive applications. There are several 80 organizations which are working on edge computing definition and 81 architecture with various emphases. For instance, ETSI MEC 82 (previously mobile edge computing and now multi-access edge 83 computing) looks at edge computing from the perspective of the edge 84 of the provider network. It also has an successive convention of 85 focusing on cellular network requirements. The Industrial Internet 86 Consortium (IIC) and Edge Computing Consortium (ECC) works on edge 87 computing in a more general view of industrial IoT, where edge 88 computing nodes are even closer to verticals (i.e. the very first 89 hops where the service is connected to the network). Typically, the 90 edge computing nodes are located at customers' premises. However, 91 IIC and ECC are not standard organizations and they rely on 92 communities such as IETF to provide protocols and API definitions for 93 their architectural use especially as Operation Technology (OT), 94 Information Technology (IT) and Communication Technology (CT) 95 converge. 97 Edge computing concepts have been presented in various groups within 98 the IETF/IRTF. The edge computing topic, similar to cloud computing, 99 is much too broad to tackle within the IETF. There are specific 100 protocol/interface areas, however, that can be worked on in the IETF 101 once we identify a specific area of focus. BEC is one of the 102 specific area which looks at edge computing from the industrial 103 verticals such as factory, hospital, power and city/ building 104 perspective and down to the level of local edge support for sensors, 105 engines, pumps and machinery. 107 A simple example, of BEC, is factory equipment having connected 108 sensors which are generating data and sending to the equipment within 109 an edge computing environment. One sensor, connected to this 110 equipment, could generate an event, such as overheating, and an 111 connected actuator could quickly increase fan span or reduce engine 112 speed depending upon the data within the local edge computing node. 113 This type of event is being controlled today within closed industrial 114 command and control protocols. But what is not generally available 115 is the ability for open edge computing equipment to generate 116 predictive maintenance and command and control across factories, 117 verticals and into the cloud. This is where we see a gap in 118 standards definitions and an opportunity for new protocols and 119 interfaces, in which IETF could play a particularly important role. 121 1.1. Requirements Language 123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 125 document are to be interpreted as described in RFC 2119 [RFC2119]. 127 1.2. Terminology 129 o BEC - Beyond Edge Computing, a concept of on-premises edge 130 computing where the devices deployed directly at customers' 131 premise are worked on. 133 2. The Concept and Capabilities of Beyond Edge Computing 135 Beyond Edge Computing (BEC) looks at the on-site intelligent 136 evolution of industrial verticals. It brings the edge computing 137 capability down to the level of customer premises, which are typical 138 beyond the access network of a service provider. 140 +-------------------------------+ 141 | Core Data Center | 142 +-------------------------------+ 143 *** Backbone 144 * * Network 145 *** 146 +-------------------------------+ 147 | Regional Data Center | 148 +-------------------------------+ 149 *** Metropolitan 150 * * Network 151 *** 152 +-------------------------------+ 153 | Local Data Center/Access Point| 154 +-------------------------------+ 155 *** Access *** 156 * * Network * * 157 *** *** 158 +-----------+ +-----------+ 159 | Beyond | | Beyond | 160 | Edge | | Edge | 161 | Computing | | Computing | 162 +-----------+ +-----------+ 164 Figure 1: Beyond Edge Computing in the Network 166 Figure 1 illustrates the schematic diagram of BEC in terms of its 167 position in a overall network. BEC takes care of the first hop where 168 the service of a particular industrial vertical connects to the 169 network. It can be regarded as an extended intelligent connectivity 170 capability of a service provider's network to industrial verticals. 171 Meanwhile, it also expands the cloud computing ability directly to 172 customers' sites. 174 2.1. Heterogeneous IoT Device Compatibility 176 Vertical industries have various interfaces for on-premises LAN and 177 WAN. This include both wireless and fixed line systems. Taking the 178 field bus as an example, 10 different specification are defined in 179 IEC61158, which is only a small portion of the existing field bus 180 technologies people can actually find in real world. BEC should 181 provide the capability of protocol translation and mapping, which 182 enables the inter-operation between different systems. 184 2.2. Deterministic Networking 186 One of the most important motivation of BEC is to reduce the 187 propagation latency by the deployment of services most closer to 188 users. However, the processing and scheduling latency cannot 189 directly benefit from closer deployment. Especially as the end-to- 190 end propagation latency for a edge service has been reduced to less 191 than 1 ms, processing and scheduling latency became even more 192 essential. At the same time, emerging services including AR/VR, 193 Remote robot system and motion control rely on not only low but also 194 a strictly deterministic latency. Real-time operation system will be 195 a preferred choice for BEC. Additionally, high-precision time 196 synchronization and packet preemption are also significant 197 characteristics for deterministic network in BEC system. 199 2.3. Management of Massive Amount of Devices 201 It is expected the hundreds of millions of BEC nodes will be deployed 202 in industrial internet scenario, typically in a form of gateway. 203 Management is the key to provide reliable and flexible edge services 204 using BEC nodes. It is preferred to have unified interface to 205 realize both device-level and resource-level management of BEC nodes. 207 2.4. Support of Network Slicing 209 An important benefit of BEC is the capability of edge service 210 deployment. Based on light-weight distributed NFV technologies, the 211 resource on BEC nodes can be dedicated for particular application. 212 At the same time, the packet of a certain edge service can be labeld 213 and steered to the preferred network slice at the WAN side, creating 214 a true end-to-end network slice for industrial verticals. 216 2.5. Multi-ecosystem Environment 218 It is preferred to have a unified set of APIs, which achieve a deep- 219 level capability exposure of the BEC nodes. The functions can be 220 exposed to the upper layer applications in terms of forwarding, 221 address, management and physical interface functionalities. 223 3. Reference Architecture 224 +--------------------------------+ 225 | BEC Management Platform | 226 | | 227 | +----------------------------+ | +-------------+ 228 | | Application Management | | | | 229 | +----------------------------+ | | IoT | 230 | +------------+ +------------+ | | Cloud | 231 | | Device | | Resource | | | Services | 232 | | Management | | Management | | | | 233 | +------------+ +------------+ | | | 234 | +----------------------------+ | | | 235 | | SDN Platform | | +----+--------+ 236 | +----------------------------+ | | 237 +--------------------------------+ | 238 | Management |Data 239 | Channel |Channel 240 +----------------------------------------------------+ 241 | +-------------v-------------------+ | | 242 | | Management Data Model | | | 243 | +---+-------+-------+---------+---+ | | 244 | | | | | | | 245 | | | | | | | 246 | | | | +------------------+ | 247 | | | | | +---------+ | | 248 | | | | | | APP | | | 249 | | | | | +---------+ | | 250 | | | | |Container/VM | | 251 | | | | +------------------+ | 252 | | | +-v----------------------------+ | 253 | | | | Virtualization Layer | | 254 | | | +------------------------------+ | 255 | | +-----v------------------------------------+ | 256 | | | API Exposure | | 257 | | +------------------------------------------+ | 258 | +---v--------------------------------------------+ | 259 | | Linux Kernel | | 260 | +------------------------------------------------+ | 261 | Ethernet Bluetooth PLC RF RS485 | 262 | WiFI FXS DI/DO RS232 | 263 +----------------------------------------------------+ 265 Figure 2: The Reference Architecture of Beyond Edge Compuring 267 Figure 2 demonstrates the reference architecture of BEC system with a 268 managed BEC node and a cloud-based management platform. An IoT 269 gateway is the typical form of a BEC node device. Gateways always 270 play important role in the Cloud-Edge architecture since they are the 271 most popular devices where verticals are provided with various 272 capabilities such as computing, storage and networking. In addition, 273 applications for various vertical customers are developed by 274 themselves or third-party while deployed on demand. Giving the edge 275 computing ability of BEC, much of the data can be processed by 276 applications running on the gateway locally as required by vertical 277 customers. The gateways are commonly versatile protocol speakers so 278 that devices speaking different protocols can communicate with the 279 them. The East-West connectivity between BEC nodes might be enabled 280 by various protocols such as OPC-UA, MQTT, TSN and other 281 deterministic Ethernet protocols, for example EtherCat, Ethernet/IP, 282 Profinet. To facilitate the operation of the BEC system, a central 283 controller in the cloud is provisioned to the customer. It mainly 284 supervise the device, virtulization resource and application life 285 cycle of the BEC node. 287 The key requirements of BEC are in providing distribution service 288 entities on the customers site (end AP, devices) to meet the growing 289 demand for low latency, reliable, and secure vertical industries. 290 The Computing, Storage, I/O isolation are remotely managed at the 291 edge to provide certain dedication and quality guarantees. Agile, 292 flexible and scalable deployment of services from operator/third 293 party down to the edge through software entities (VM/ Containers). A 294 light weight MANO like approach is needed to provide resource 295 provisioning and VNF deployment. A unified API definition is needed 296 to support the co- existence of multi-ecosystem at the BEC node. And 297 there needs to be the ability for the edge device to map specific 298 service requirements with an end to end network slice with certain 299 guarantees and pass the policy identification along the path to the 300 centralized DC. 302 4. Use Cases of BEC 304 1. Elevator Networks 306 Description: There are more than 15 million elevators around the 307 world and the daily maintenance of these elevators costs elevator 308 operators a large amount of revenue. An elevator usually carries 309 hundreds of sensors which are generating a large amount of data to be 310 uploaded to the cloud. The BEC nodes can preprosess the data 311 gathered from elevator sensors so that the volume to be uploaded to 312 the Cloud is greatly reduced. Based on the input from elevator 313 sensors, AI programs installed on BEC nodes may locally make 314 decisions without the intervention of the Cloud. For example, when 315 the noise or vibration of an elevator exceeds a certain level, the 316 BEC node may notify elevator maintainers to reach this elevator and 317 perform maintanence or repair. 319 Goal: BEC nodes are deployed into elevators to gather/preprocess/ 320 compress the data to save the communication cost. Based on the data 321 gathered from elevator sensors, BEC nodes can assist operators to do 322 predictive maintenance. 324 Requirements: Customized gateways operated by elevator providers. An 325 open platform with VMs/containers which can hold customized Apps. 326 These Apps are managed by elevator operators while developed by 327 gateway vendors or any other third parties. Various connectivities 328 are supported (2G/3G/LTE/eMTC/Ethernet) by BEC nodes. A central 329 controller to perform configuration and management of the network. 330 AI models are trained on the Cloud while the reasoning of these AI 331 models are performed at the Edge. 333 2. Intelligent Street Lights 335 Description: BEC nodes are placed on street lights to act as board 336 routers of LLNs. BEC nodes may act as RSUs of vehicle networks. 337 With AI programs installed on the BEC nodes, reasoning and decisions 338 might be made locally at the edge. For example, For example, BEC 339 nodes can adjust the lights' brightness and operating hours according 340 to environment parameters, providing illumination when needed while 341 reducing power consumption. With sensors on trash cans, BEC nodes 342 are aware whether a trash can is full. Trash collecting cars can 343 communicate with the BEC nodes to determine whether to reach a trash 344 can to collect the trash. 346 Goal: BEC nodes gather data from sensors which are used to monitor 347 various information (e.g., brightness, temperature, humidity) of a 348 district. 350 Requirements: BEC nodes SHOULD support ROLL [RFC] in order to join 351 the LLN as a board router. Various wired/wireless communication 352 protocols such as Radio Frequency (RF) protocols (e.g., Zigbee, WI- 353 SUN) and Power Line Communication (PLC) should be supported. The BEC 354 nodes can use 2G/3G/LTE/Ethernet to communicate with the Cloud. 356 3. Smart Manufacturing 358 Description: BEC nodes join the industiral manufacturing network and 359 provide the networking function. Control messages that requires 360 deterministic latency will be carried on this network. BEC nodes 361 need to support deteministic networking protocols such IEEE Time 362 Sensitive Networking (TSN), Profinet, Ethernet/IP, EtherCat, etc. 364 The gateway can also help monitor the equipments' status, and send 365 out alarms or warnings when malfunction is detected or predicted. 367 Goal: Edge computing enables interconnection of deterministic 368 networks. 370 Requirements: BEC nodes should support industrial machine-to-machine 371 message bus connectivity protocols such as OPC-UA, DDS, MQTT. The 372 network may be configured by a central controller using Netconf/YANG. 373 BEC nodes should support the interconnection of heterogeneous 374 deterministic Ethernet protocols. 376 4. Smart grid 378 Description: BEC nodes can be deployed in three scenarios of the 379 smart grid. In advanced metering infrastructure (AMI), besides the 380 routing function, it can also act as a concentrator to collect and 381 aggregate the meters' data. It can also provide primary analysis to 382 detect theft and outage. Firewall function can be deployed at the 383 gateway to deal with attacks from the edge. In distribution 384 automation (DA), BEC nodes provide bounded latency connection between 385 controller and actuators such as switches and transformers. Edge 386 computing applications can be implemented on these devices to monitor 387 the status and react rapidly to faults. In terms of microgrid, the 388 BEC node monitors the local power generation and storage, and helps 389 smoothly integrate the energy generated by photovoltaic panels and 390 wind turbines, whose power is very unstable, into the macro grid. 392 Goal: In AMI, the BEC node works as a router, firewall and 393 concentrator, providing data preprocess services. In DA, BEC node 394 enables the deterministic connection between controllers and 395 actuators. In microgrid, BEC node is the coordinator between 396 distributed and centralized generation. 398 Requirements: The gateway should support various wired/wireless 399 communication protocols, such as Power Line Communication (PLC), 400 Radio Frequency (RF), NB-IOT and 2G/3G/LTE. Bounded latency is 401 required in automation use cases. Open platforms are needed to 402 accommodate various applicaitons providing data analysis, fault 403 detection and automation control capabilities. 405 5. IANA Considerations 407 N/A 409 6. Security Considerations 411 Security considerations will be a critical component of IIoT edge 412 computing particularly as intelligence is moved to the extreme edge. 414 7. Acknowledgement 416 The authors would like to thank Sami Kekki for his feedback on this 417 draft. 419 8. Normative References 421 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 422 Requirement Levels", BCP 14, RFC 2119, 423 DOI 10.17487/RFC2119, March 1997, 424 . 426 Authors' Addresses 428 Liang Geng 429 China Mobile 431 Email: gengliang@chinamobile.com 433 Mingui (Martin) Zhang 434 Huawei 436 Email: zhangmingui@huawei.com 438 Mike McBride 439 Huawei 441 Email: michael.mcbride@huawei.com 443 Bing Liu 444 Huawei 446 Email: remy.liubing@huawei.com