idnits 2.17.1 draft-defoy-t2trg-iot-edge-computing-background-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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (25 May 2020) is 1429 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group X. de Foy 3 Internet-Draft InterDigital Communications, LLC 4 Intended status: Informational J. Hong 5 Expires: 26 November 2020 Y-G. Hong 6 ETRI 7 M. Kovatsch 8 Huawei Technologies Duesseldorf GmbH 9 E. Schooler 10 Intel 11 D. Kutscher 12 University of Applied Sciences Emden/Leer 13 25 May 2020 15 IoT Edge Computing: Initiatives, Projects and Products 16 draft-defoy-t2trg-iot-edge-computing-background-00 18 Abstract 20 Many IoT applications have requirements that cannot be met by 21 the traditional Cloud. As a result, the IoT is driving the Internet 22 toward Edge computing. This draft reviews initiatives, projects and 23 products related to IoT Edge Computing. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on 26 November 2020. 42 Copyright Notice 44 Copyright (c) 2020 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 49 license-info) in effect on the date of publication of this document. 50 Please review these documents carefully, as they describe your rights 51 and restrictions with respect to this document. Code Components 52 extracted from this document must include Simplified BSD License text 53 as described in Section 4.e of the Trust Legal Provisions and are 54 provided without warranty as described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Open Source Projects . . . . . . . . . . . . . . . . . . . . 3 60 2.1. Gateway/CPE Platforms . . . . . . . . . . . . . . . . . . 3 61 2.2. Edge Cloud Management Platforms . . . . . . . . . . . . . 4 62 2.3. Related Projects . . . . . . . . . . . . . . . . . . . . 5 63 3. Products . . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 3.1. IoT Gateways . . . . . . . . . . . . . . . . . . . . . . 5 65 3.2. Edge Cloud Platforms . . . . . . . . . . . . . . . . . . 6 66 4. Standards Initiatives . . . . . . . . . . . . . . . . . . . . 6 67 4.1. ETSI Multi-access Edge Computing . . . . . . . . . . . . 6 68 4.2. Edge Computing Support in 3GPP . . . . . . . . . . . . . 7 69 4.3. OpenFog and Industrial Internet Consortium . . . . . . . 8 70 4.4. Related Standards . . . . . . . . . . . . . . . . . . . . 8 71 5. Research Projects . . . . . . . . . . . . . . . . . . . . . . 8 72 5.1. Named Function Networking . . . . . . . . . . . . . . . . 8 73 5.2. 5G-CORAL . . . . . . . . . . . . . . . . . . . . . . . . 9 74 6. Informative References . . . . . . . . . . . . . . . . . . . 9 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 77 1. Introduction 79 This list of open-source or commercial products, standard initiatives 80 and research projects aims to provide an overview of the IoT edge 81 computing. 83 It has been developped in support of [IOT-EDGE]. This other draft 84 studies challenges and functions associated with IoT edge computing, 85 and provides further background information on IoT, cloud computing 86 and edge computing. 88 Our goal is to be representative rather than exhaustive. Please help 89 us complete this overview by communicating with us about entries we 90 have missed. 92 2. Open Source Projects 94 2.1. Gateway/CPE Platforms 96 EdgeX Foundry, Home Edge, Edge Virtualization Engine are Linux 97 Foundation projects ([Linux_Foundation_Edge]) aiming to provide a 98 platform for edge computing devices. 100 Such an open source platform can, for example, host proprietary 101 programs currently run on IoT gateway products (Section 3). 103 EdgeX Foundry develops an edge computing framework running on the IoT 104 gateway. 106 Home Edge develops an edge computing framework especially dedicated 107 to home computing devices, controlling home appliances, sensors, 108 etc., and enabling AI applications, especially distributed and 109 parallel machine learning. 111 The Edge Virtualization Engine (EVE) project develops a 112 virtualization platform (for VMs and containers) designed to run 113 outside of the datacenter, in an edge network; EVE is deployed on 114 bare-metal hardware. 116 Computing devices: Hardware support for EdgeX and EVE is similar: 117 they support x86 and ARM-based computing devices; A typical target 118 can be a Linux Raspberry Pi with 1GB RAM, 64bit CPU, 32GB storage. 120 Service platform: EdgeX uses a micro-service architecture. Micro- 121 services on the gateway are connected together, and to outside 122 applications, through REST, or messaging technologies such as 123 MQTT, AMQP and 0MQ. The gateway can communicate with external 124 backend applications or other gateways (north-south in tiered 125 deployments or east-west in more distributed deployments). 126 Gateway-device communication can use a wide range of IoT 127 protocols. "Export services" enable on-gateway and off-gateway 128 clients to register as recipient for data from devices. Core 129 services are microservices that deal with persisting data from 130 devices or alternatively "streaming" device data through, without 131 persistence (core data service); managing information about the 132 IoT devices, including their sensors, how to communicate with 133 them, etc. (metadata service); and actual communication with IoT 134 devices, on behalf of other on-gateway or off-gateway services 135 (command service). A rule engine provides an API to register 136 actions in response to conditions typically including an IoT 137 device ID, sensor values to check, thresholds, etc. The 138 scheduling micro service deals with organizing the removal of data 139 persisted on the gateway. Alerts and notifications microservice 140 can be used to dispatch alert/notifications from internal or 141 external sources to interested consumers including backend 142 servers, or human operators through email or SMS. 144 Edge cloud applications: Target applications for EdgeX include 145 Industrial IoT (e.g., IoT sensor data and actuator control mixed 146 with augmented reality application for technicians). Home Edge 147 focuses on smart home use cases, including using AI lifestyle and 148 safety applications. 150 2.2. Edge Cloud Management Platforms 152 This set of open-source projects setup and manage clouds of 153 individual edge computing devices. 155 StarlingX ([StarlingX]) extends OpenStack to provide virtualization 156 platform management for edge clouds, which are distributed (in the 157 range of 100 compute devices), secure and highly available. 159 Akraino Edge Stack, another project from the Linux Fundation Edge 160 [Linux_Foundation_Edge], has a wider scope of developing a management 161 platform adapted for the edge (e.g., covering 1000 plus locations), 162 aiming for zero-touch provisioning, and zero-touch lifecycle 163 management. 165 Computing devices: Compute devices are typically Linux-based 166 application servers or more constrained devices. 168 Service platform: StarlingX adds new management services to 169 OpenStack by leveraging building blocks such as Ceph for 170 distributed storage, Kubernetes for orchestration. The new 171 services are for management of configuration (enabling auto- 172 discovery and configuration), faults, hosts (enabling host failure 173 detection and auto-recovery), services (providing high 174 availability through service redundancy and multi-path 175 communication) and software (enabling updates). 177 Edge cloud applications: An edge computing platform may support a 178 wide range of use cases. E.g., autonomous vehicles, industrial 179 automation and robotics, cloud RAN, metering and monitoring, 180 mobile HD video, content delivery, healthcare imaging and 181 diagnostics, caching and surveillance, augmented/virtual reality, 182 small cell services for high density locations (stadiums), 183 universal CPE applications, retail. 185 2.3. Related Projects 187 Open Edge Computing ([OpenEdgeComputing]) is an initiative from 188 universities, manufacturers, infrastructure providers and operators, 189 enabling efficiently offloading cloudlets (VMs) to the edge. 190 Computing devices are typically powerful, well-connected servers 191 located in mobile networks (e.g., collocated with base stations or 192 aggregation sites). The service platform is built on top of 193 OpenStack++, an extension of OpenStack to support cloudlets. This 194 project is mentioned here as a related project because of its edge 195 computing focus, and potential for some IoT use cases. Nevertheless, 196 its primary use cases are typically non-IoT related, such as 197 offloading processing-intensive applications from a mobile device to 198 the edge. 200 3. Products 202 3.1. IoT Gateways 204 Multiple products are marketed as IoT gateways (Amazon Greengrass, 205 Microsoft Azure IoT Edge, Google Cloud IoT Core, and gateway 206 solutions from Bosh and Siemens). They are typically composed of a 207 software frameworks that can run on a wide range of IoT gateway 208 hardware devices to provide local support for cloud services, as well 209 as some other local IoT gateway features such as relaying 210 communication and caching content. Remote cloud is both used for 211 management of the IoT gateways, and for hosting customer application 212 components. Some IoT gateway products (Amazon Snowball) have a 213 primary purpose of storing edge data on premises, to enable 214 physically moving this data into the cloud without incurring digital 215 data transfer cost. 217 Computing devices: Typical computing devices run Linux, Windows or a 218 Real-Time OS over an ARM or x86 architecture. The level of 219 service support on the computing device can range from low-level 220 packages giving maximum control to embedded developers, to high- 221 level SDKs. Typical requirements can start at 1GHz and 128MB RAM, 222 e.g., ranging from Raspberry Pi to a server-level appliance. 224 Service platform: IoT gateways can provide a range of service 225 including: running stateless functions; routing messages between 226 connected IoT devices (using a wide range of IoT protocols); 227 caching data; enabling some form of synchronization between IoT 228 devices; authenticating and encrypting device data. Association 229 between IoT devices and gateway based can require a device 230 certificate. 232 Edge cloud applications: Pre-processing of IoT data for later 233 processing in the cloud is a major driver. Use cases include 234 industrial automation, farming, etc. 236 3.2. Edge Cloud Platforms 238 Services such as MobileEdgeX provide a platform for application 239 developers to deploy software (e.g., as software containers) on edge 240 networks. 242 Computing devices: Bare metal and virtual servers provided by mobile 243 network operators are used as computing devices. 245 Service platform: The service platform provides end device location 246 service, using GPS data obtained from platform software deployed 247 in end devices, correlated with location information obtained from 248 the mobile network. The service platform manages the deployment 249 of application instances (containers) on servers close to end 250 devices, using a declarative specification of optimal location 251 from the application provider. 253 Edge cloud applications: Use cases include autonomous mobility, 254 asset management, AI-based systems (e.g., quality inspection, 255 assistance systems, safety and security cameras) and privacy- 256 preserving video processing. There are also non-IoT use cases 257 such as augmented reality and gaming. 259 4. Standards Initiatives 261 4.1. ETSI Multi-access Edge Computing 263 The ETSI MEC industry standardization group develops specifications 264 that enable efficient and seamless integration of applications from 265 vendors, service providers, and 3rd parties across multi-vendor MEC 266 platforms ([ETSI_MEC_03]). 268 Basic principles followed include: leveraging NFV infrastructure; 269 being compliant with 3GPP systems; focusing on orchestration, MEC 270 services, applications and platforms. 272 Phase 1 (2015-2016) focused on basic platform services. Phase 2 273 (2017-2019) focuses on: supporting non-3GPP radio access 274 technologies, especially WiFi; supporting a distributed, multi- 275 operator and multi-vendor architecture; supporting non-VM based 276 virtualization such as containers and PaaS. 278 Computing devices: Computing devices are typically application 279 servers, attached to an eNodeB or at a higher level of aggregation 280 point, and provide service to end users. 282 Service platform: The mobile edge platform offers an environment 283 where the mobile edge applications can discover, advertise, 284 consume and offer mobile edge services. The platform can provide 285 certain native services such as radio network information, 286 location, bandwidth management etc. The platform manager is 287 responsible for managing the life cycle of applications including 288 informing the mobile edge orchestrator of relevant application 289 related events, managing the application rules and requirements 290 including service authorizations, traffic rules, DNS 291 configuration. 293 Edge cloud applications: Some of the use cases for MEC 294 ([ETSI_MEC_02]) are IoT-related, including: security and safety 295 (face recognition and monitoring), sensor data monitoring, active 296 device location (e.g., crowd management), low latency vehicle-to- 297 infrastructure and vehicle-to-vehicle (V2X, e.g., hazard 298 warnings), video production and delivery, camera as a service. 300 4.2. Edge Computing Support in 3GPP 302 The 3GPP standards organization included edge computing support in 5G 303 [_3GPP.23.501]. Integration of MEC and 5G systems has been studied 304 in ETSI as well [ETSI_MEC_WP_28]. 306 Computing devices: From 3GPP standpoint, a mobile device may access 307 any computing device located in a local data network, i.e., 308 traffic is steered towards the local data network where the 309 computing device is located. 311 Service platform: An external party may influence steering, QoS and 312 charging of traffic towards the computing device. Session and 313 service continuity can ensure that edge service is maintained when 314 a client device moves. The network supports multiple-anchor 315 connections, which makes it possible to connect a client device to 316 both a local and a remote data network. The client device can be 317 made aware of the availability of a local area data network, based 318 on its location. 320 Edge cloud applications: Edge cloud applications in 3GPP can help 321 support the major use cases envisioned for 5G, including massive 322 IoT and V2X. 324 4.3. OpenFog and Industrial Internet Consortium 326 The OpenFog Consortium (now merged with the Industrial Internet 327 Consortium) aims to standardize industrial IoT, fog, and edge 328 computing. It produced a reference architecture for the fog 329 ([OpenFog]), which has been published as IEEE standard P1934 in 2018. 330 This work continues within the Industrial Internet Consortium. 332 Computing devices: Fog nodes include computational, networking, 333 storage and acceleration elements. This includes nodes collocated 334 with sensors and actuators, roadside or mobile nodes involved in 335 V2X connectivity. Fog nodes should be programmable and may 336 support multi-tenancy. Fog computing devices must employ a 337 hardware-based immutable root of trust, i.e., a trusted hardware 338 component which receives control at power-on. 340 Service platform: The service platform is structured around 341 "pillars" including: security end-to-end, scalability by adding 342 internal components or adding more fog nodes,openness in term of 343 discovery of/by other nodes and networks, autonomy from 344 centralized clouds (for discovery, orchestration and management, 345 security and operation) and hierarchical organization of fog 346 nodes. 348 Edge cloud applications: Major use cases include smart cars and 349 traffic control, visual security and surveillance, smart cities. 351 4.4. Related Standards 353 The IEEE Fog Computing and Networking Architecture Framework Working 354 Group [IEEE-1934] published the OpenFog architecture as an IEEE 355 document, and plan to do further work on taxonomy, architecture 356 framework, and compliance guidelines. 358 5. Research Projects 360 5.1. Named Function Networking 362 Named Function Networking ([Sifalakis]) is a research project that 363 aims to extend ICN concepts (especially named data networking) to 364 have the network orchestrate computation. Interests are sent for a 365 combination of function and argument names, instead of using the 366 content name in NDN. 368 Computing devices: NFN-capable switches are collocated with 369 computing devices. 371 Service platform: NFN enables accessing static data and dynamic 372 computation results in one data-oriented framework, thus 373 benefiting from usual ICN features such as data authenticity and 374 caching, as well as enabling the network to perform various 375 optimizations, e.g., moving data, code or both closer to 376 requesters. NFN also enables secure access to individual elements 377 within Named Data Objects, e.g., for filtering or aggregation. 379 Edge cloud applications: Use cases include some form of MapReduce 380 operations and service chaining. NDN, on which NFN is based, has 381 been studied in the context of IoT, where it can provide local 382 trust management and rendezvous service. 384 5.2. 5G-CORAL 386 The 5G-CORAL project ([_5G-CORAL]) aims to enable convergence of 387 access across multiple radio access technologies using fog computing, 388 using for this purpose an edge and fog computing system (EFS). 390 Computing devices: Computing devices used in 5G-CORAL include cloud 391 and central data center servers, edge data center servers, and 392 fixed or mobile "fog computing devices", which can be computing 393 devices located in vehicles or factories, e.g., IoT gateways, 394 mobile phones, cyber-physical devices, etc. 396 Service platform: 5G-CORAL architecture is based on an integrated 397 virtualized edge and fog computing system (EFS), that aims to be 398 flexible, scalable and interoperable with other domains including 399 transport (fronthaul, backhaul), core and clouds. An 400 Orchestration and Control System (OCS) enables automatic discovery 401 of heterogeneous, multiple-owner resources, and federate them into 402 a unified hosting environment. OCS monitors resource usage to 403 guarantee service levels. Finally, OCS also includes 404 orchestration and life cycle functions, including live migration 405 and scaling. Applications (user and third-party) both inside and 406 outside the EFS subscribe to EFS services through APIs, with 407 emphasis on IoT and cyber-physical functionalities. 409 Edge cloud applications: EFS-hosted services include analytics 410 obtained from IoT gateways (e.g., LORA or eNodeB gateways), 411 context information services from RATs, transport (fronthaul and 412 backhaul) and core networks. EFS-hosted functions include network 413 performance acceleration functions, virtualized C-RAN functions 414 for access nodes and possible end user devices. 416 6. Informative References 418 [ETSI_MEC_02] 419 ETSI, ., "Multi-access Edge Computing (MEC); Phase 2: Use 420 Cases and Requirements", ETSI GS 002 , 2016, 421 . 424 [ETSI_MEC_03] 425 ETSI, ., "Mobile Edge Computing (MEC); Framework and 426 Reference Architecture", ETSI GS 003 , 2019, 427 . 430 [ETSI_MEC_WP_28] 431 ETSI, ., "MEC in 5G networks", White Paper , 2018, 432 . 435 [IEEE-1934] 436 IEEE, ., "FOG - Fog Computing and Networking Architecture 437 Framework", Portal , 2019, 438 . 440 [IOT-EDGE] Hong, J., Hong, Y-G., de Foy, X., Kovatsch, M., Schooler, 441 E., and D. Kutscher, "IoT Edge Challenges and Functions", 442 Work in Progress, Internet-Draft, draft-hong-t2trg-iot- 443 edge-computing, . 446 [Linux_Foundation_Edge] 447 Linux Foundation, ., "Linux Foundation Edge", Portal , 448 2019, . 450 [OpenEdgeComputing] 451 "Open Edge Computing", Portal , 2019, 452 . 454 [OpenFog] "OpenFog Reference Architecture for Fog Computing", 455 OpenFog Consortium , 2017. 457 [Sifalakis] 458 Sifalakis, M., Kohler, B., Scherb, C., and C. Tschudin, 459 "An Information Centric Network for Computing the 460 Distribution of Computations", Proceedings of the 1st 461 International Conference on Information-centric networking 462 (INC) , 2014. 464 [StarlingX] 465 OpenStack Foundation, ., "StarlingX", Portal , 2019, 466 . 468 [_3GPP.23.501] 469 3GPP, ., "System Architecture for the 5G System", 3GPP TS 470 23.501 , 2019, 471 . 473 [_5G-CORAL] 474 Horizon 2020 Programme, ., "5G Convergent Virtualised 475 Radio Access Network Living at the Edge (5G-CORAL) 476 Project", Portal , 2019, . 478 Authors' Addresses 480 Xavier de Foy 481 InterDigital Communications, LLC 482 1000 Sherbrooke West 483 Montreal H3A 3G4 484 Canada 486 Email: xavier.defoy@interdigital.com 488 Jungha Hong 489 ETRI 490 218 Gajeong-ro, Yuseung-Gu 491 Daejeon 493 Email: jhong@etri.re.kr 495 Yong-Geun Hong 496 ETRI 497 218 Gajeong-ro, Yuseung-Gu 498 Daejeon 500 Email: yghong@etri.re.kr 502 Matthias Kovatsch 503 Huawei Technologies Duesseldorf GmbH 504 Riesstr. 25 C // 3.OG 505 80992 Munich 506 Germany 508 Email: ietf@kovatsch.net 509 Eve Schooler 510 Intel 511 2200 Mission College Blvd. 512 Santa Clara, CA, 95054-1537 513 United States of America 515 Email: eve.m.schooler@intel.com 517 Dirk Kutscher 518 University of Applied Sciences Emden/Leer 519 Constantiaplatz 4 520 26723 Emden 521 Germany 523 Email: ietf@dkutscher.net