idnits 2.17.1 draft-nordmark-t2trg-computing-edge-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 22, 2018) is 2005 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) == Outdated reference: A later version (-02) exists of draft-hong-iot-edge-computing-01 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Nordmark 3 Internet-Draft Zededa 4 Intended status: Standards Track October 22, 2018 5 Expires: April 25, 2019 7 Computing at the edge 8 draft-nordmark-t2trg-computing-edge-00 10 Abstract 12 There has been some discussion about edge computing in the T2TRG. 13 This note explores the edge from a computing perspective, and from 14 that suggests aspects of networking that relate to edge computing. 15 It includes some potential research problems for networking edge 16 computing. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on April 25, 2019. 35 Copyright Notice 37 Copyright (c) 2018 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. What is computing? . . . . . . . . . . . . . . . . . . . . . 2 54 3. What is edge? . . . . . . . . . . . . . . . . . . . . . . . . 3 55 4. Why edge computing? . . . . . . . . . . . . . . . . . . . . . 4 56 5. Networking for Edge Computing . . . . . . . . . . . . . . . . 5 57 6. Application connectivity . . . . . . . . . . . . . . . . . . 5 58 7. Potential research topics . . . . . . . . . . . . . . . . . . 6 59 8. Security Considerations . . . . . . . . . . . . . . . . . . . 6 60 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 61 10. Informative References . . . . . . . . . . . . . . . . . . . 7 62 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 64 1. Introduction 66 Edge computing has gained increased interest industry over the last 67 few years and there has already been some discussion in the IETF and 68 IRTF as exemplified by [I-D.zhang-iiot-edge-computing-gap-analysis], 69 [I-D.hong-iot-edge-computing], and 70 [I-D.geng-iiot-edge-computing-problem-statement]. This note builds 71 on that work while taking a step back from the networking aspects to 72 look at how computing would happen at the edge and what is needed to 73 satisfy that computing. The note also tries to separate out the 74 motivations for computing edge from the attributes of the edge. 76 2. What is computing? 78 The general notion of computing is likely to be clear; some 79 programmable ability in the form of CPU/GPU plus some memory, with 80 some ability to interact with the external word (I/O, networking), 81 with optional ability to store data locally with persistence. 83 However, it might be useful to try to separate the flexibility of 84 edge computing from fixed function devices which do not have the 85 capacity or flexibility to perform other functions than envisioned 86 prior to their deployment. Such fixed function devices still require 87 a software/firmware update capability as discussed in [RFC8240], but 88 they do not require handling new application deployment and 89 associated new communication patterns. 91 These more flexible devices are likely to be larger than the class 2 92 devices defined in [RFC7228], however if applications are 93 sufficiently small, constrained devices might very well be edge 94 computing devices. But in general it makes sense to think about 95 devices of the Raspberry Pi class and larger. 97 If the set of applications which might be deployed on a device isn't 98 known prior to deployment it might be difficult to determine a 99 utility cycle and resulting upper bound on power consumption. As 100 such it is hard to envision this flexibility for devices which need 101 to run for years on a battery or using energy harvesting. 103 One way to envision edge computing is to think of a developer or a 104 devops person wanting to run computation closer to the sensors and 105 actuators, but with the same ease as running computation in the cloud 106 (e.g, docker, kubernetes). In that vein one can think of existing 107 applications with a new deployment target; deploy to all the light- 108 poles in Palo Alto as opposed to a cloud availability zone. Of 109 course the industry will also develop new applications and new 110 applications for the edge, but some applications are likely to 111 migrate from the cloud or be existing standalone applications. 113 In some cases it is useful to make a distinction between a device and 114 an (IoT) gateway in this context. However, the term gateway might 115 mean very different things. In some cases it is a product category, 116 referring to compact and passively cooled PCs with rich physical 117 connectivity e.g., RS485 ports and multiple Ethernet ports, etc. 118 That generalizes to an architectural node which has a router and 119 protocol translators e.g., from Modbus to MQTT. In other cases it 120 refers to nodes which run software to translate one data model to 121 another one as in [I-D.iab-iotsi-workshop]. 123 We might see architectural patterns in the future which separate 124 fixed function devices (in particular those with hardware crypto 125 implementations) with long deployment lifetimes from the larger 126 Internet and its threats and need for crypto agility by interposing a 127 "gateway" device which limits the security exposure for those fixed 128 function devices. However, we have yet to see that architectural 129 pattern develop. 131 3. What is edge? 133 As edge computing is gaining popularity the term seems to be applied 134 to refer to a large range of things: 136 o In the context of Industry 4.0 the edge is where the actions are 137 to be taken based on the analyzed data, thus in or near the 138 machines in the factory. 139 o The Industrial Internet Consortium (IIC) refers to the edge as 140 customer premise equipment i.e., equipment deployed in the 141 enterprise. 142 o ETSI MEC refers to the edge of provider network, i.e., the 143 provider edge. 145 o Some datacenter operators with many smaller datacenters offer edge 146 computing solutions since they claim being closer to the users 147 than the large cloud operators. 148 o There is also the Internet Edge (where the large Content Delivery 149 Networks tend to be deployed) and the datacenter edge. 151 From an architectural perspective what matters is not the term but 152 what the characteristics are. As you move further and further out 153 towards the premises and enterprises some new characteristics appear 154 compared to running inside a datacenter, large or small. These apply 155 to varying degrees whether that edge device is in a light pole in a 156 smart city, on a factory floor, on an oil rig, or on a truck. 158 o Less physical security - not the same physical access control. 159 o Different network security - there might not be a firewall between 160 it and the Internet 161 o (Physical) location is key in many cases; need to be in BTLE range 162 or have the camera pointing at the right road intersection. 163 o Scale is likely to be much larger than the cloud datacenters 164 because devices need to exist in all the locations which matter. 165 o Less network transparency; NATs and/or firewalls could exist 166 between the elements of the computation at the edge. 167 o Richer uplink networking (such as Ethernet, LTE, WiFi, etc). 168 Might have redundant uplinks using different technologies. 169 o Might require specific downlink connectivity (6lo, BTLE, RS485, 170 etc) 171 o Intermittent connectivity more likely than inside datacenter. 172 o Normally no fallback network such as serial console, management 173 network, or remote power control to handle software updates gone 174 wrong. 176 4. Why edge computing? 178 The benefits of moving computing closer the sensors and actuators 179 seems to fall in three categories: 181 o Lower latency, for instance to handle process control where 182 decisions need to be made locally. 183 o Cost of bandwidth. In many cases sending all the data to the 184 cloud to perform data aggregation and run analytics can get quite 185 expensive compared to local aggregation and analytics. 186 o Autonomy and failure resiliency. A machine on the factory floor 187 needs to continue to work even if the Internet/cloud connectivity 188 is temporarily out. 190 Some documents also mention data jurisdiction as a key benefit. That 191 seems to be more an issue with keeping the data in the same 192 enterprise and same country and the data origin, and not about 193 keeping it as close as possible to the sensors and actuators. 195 5. Networking for Edge Computing 197 From the above list several of the different attributes between the 198 datacenter and the edge are about connectivity. In general the 199 connectivity is a lot more diverse at the edge than in the 200 datacenter. 202 Solutions need to handle at least Ethernet, WiFi, LTE, IPv4/IPv6, 203 redundant/multihomed connectivity, mobility, and NATs. Ideally the 204 applications which are deployed at the edge should not be required to 205 handle this diversity but instead operate the same as in the cloud 206 where the applications see DNS and IP connectivity. 208 In addition, if the applications are structured as communicating 209 (micro) services when deployed in the cloud, they are likely to 210 assume some level of network isolation (security groups etc) from the 211 infrastructure. In order to be able to deploy such applications at 212 the edge the infrastructure needs to provide at least the same level 213 of isolation, and due to the more challenging security environment at 214 the edge, it probably needs to be stronger. 216 6. Application connectivity 218 Earlier work [RFC7452] outlines three different communication 219 patters: 221 o Device-to-Device Communication Pattern 222 o Device-to-Cloud Communication Pattern 223 o Device-to-Gateway Communication Pattern 225 For the purposes of this note we separate the Device-to-Device 226 pattern into a topology-specific pattern and a topology independent. 228 The topology-specific D2D pattern is where a set of devices are e.g., 229 on the same link hence can make assumptions about discovery and 230 security that are related to the link's properties. Such deployments 231 are common today for certain applications. 233 The topology-independent D2D pattern is examplified by an application 234 deployment pattern where one microservice needs e.g., a GPU for 235 running a model and the GPU might exist in the same building or site 236 but on a different network perhaps separated by NATs. To enable the 237 promise of flexibility for edge computing the infrastructure needs to 238 be able to support such a communication pattern, which places new 239 requirements on discovery and security even when all of the edge 240 infrastructure is under common administrative control. 242 The Device-to-Cloud Communication Pattern [RFC7452] is commonly being 243 deployed today, but does not necessarily handle the applications with 244 real-time considerations. 246 The Device-to-Gateway Communication Pattern [RFC7452] can mean 247 different things depending on what type of gateway is at play. In 248 current deployment it seems to imply that the application topology is 249 the same as the network topology. For instance, the devices connect 250 over one protocol to a gateway, and that physical gateway is the only 251 one which can run the applications (be they simple protocol 252 translators or analytics/AI) which serve those devices. Over time 253 one would expect to see the application/micro-service topology to be 254 unrelated to the network topology; that is how the datacenter and 255 cloud has evolved. 257 7. Potential research topics 259 As discussed in the previous section there are likely to be 260 additional needs to enable micro-services at the edge which has the 261 different attributes we have identified. However, most of that might 262 be an engineering exercise. 264 That assumes a single asset owner controlling some set of devices, 265 gateways, and compute elements. In the case of that asset owner 266 leasing space for VMs or containers those technologies as used in the 267 cloud can be reused for multi-tenancy. However, orchestration might 268 need to be different due to the importance of location for edge 269 computing. 271 If we envision a future where we want to enable more flexible 272 resource sharing, e.g., shop owners on a street in Sao Paulo be able 273 to offer their spare CPU and GPU capacity to their neighbors with 274 some compensation/tokens, there will be additional issues around 275 trust, compensation, discovery, etc. 277 8. Security Considerations 279 This note touches on both system security and communication security. 281 9. IANA Considerations 283 There are no IANA actions needed for this document. 285 10. Informative References 287 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 288 Constrained-Node Networks", RFC 7228, 289 DOI 10.17487/RFC7228, May 2014, . 292 [RFC7452] Tschofenig, H., Arkko, J., Thaler, D., and D. McPherson, 293 "Architectural Considerations in Smart Object Networking", 294 RFC 7452, DOI 10.17487/RFC7452, March 2015, 295 . 297 [RFC8240] Tschofenig, H. and S. Farrell, "Report from the Internet 298 of Things Software Update (IoTSU) Workshop 2016", 299 RFC 8240, DOI 10.17487/RFC8240, September 2017, 300 . 302 [I-D.iab-iotsi-workshop] 303 Jimenez, J., Tschofenig, H., and D. Thaler, "Report from 304 the Internet of Things (IoT) Semantic Interoperability 305 (IOTSI) Workshop 2016", draft-iab-iotsi-workshop-02 (work 306 in progress), July 2018. 308 [I-D.zhang-iiot-edge-computing-gap-analysis] 309 Zhang, M., Liu, B., McBride, M., Hu, C., and L. Geng, "Gap 310 Analysis of Edge Computing for Industrial IoT", draft- 311 zhang-iiot-edge-computing-gap-analysis-00 (work in 312 progress), March 2018. 314 [I-D.hong-iot-edge-computing] 315 Hong, J., Hong, Y., and J. Youn, "Problem Statement of IoT 316 integrated with Edge Computing", draft-hong-iot-edge- 317 computing-01 (work in progress), October 2018. 319 [I-D.geng-iiot-edge-computing-problem-statement] 320 Geng, L., Zhang, M., McBride, M., and B. Liu, "Problem 321 Statement of Edge Computing on Premises for Industrial 322 IoT", draft-geng-iiot-edge-computing-problem-statement-01 323 (work in progress), March 2018. 325 Author's Address 327 Erik Nordmark 328 Zededa 329 Santa Clara, CA 330 USA 332 Email: nordmark@sonic.net