idnits 2.17.1 draft-bellavista-semantic-sdn-mom-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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (3 March 2022) is 784 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'BELLAVISTA2018' is defined on line 581, but no explicit reference was found in the text == Unused Reference: 'BELLO2020' is defined on line 589, but no explicit reference was found in the text == Unused Reference: 'KAUR2018' is defined on line 601, but no explicit reference was found in the text == Unused Reference: 'LI2018' is defined on line 608, but no explicit reference was found in the text == Unused Reference: 'NATESHA2021' is defined on line 615, but no explicit reference was found in the text == Unused Reference: 'RFC5870' is defined on line 628, but no explicit reference was found in the text == Outdated reference: A later version (-04) exists of draft-farrel-irtf-introduction-to-semantic-routing-03 Summary: 0 errors (**), 0 flaws (~~), 9 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TODO Working Group P. Bellavista 3 Internet-Draft L. Foschini 4 Intended status: Informational L. Patera 5 Expires: 4 September 2022 University of Bologna 6 M. Fogli 7 C. Giannelli 8 C. Stefanelli 9 University of Ferrara 10 D.Z. Lou 11 Huawei 12 3 March 2022 14 A Framework for QoS-Enabled Semantic Routing in Industrial Networks 15 draft-bellavista-semantic-sdn-mom-00 17 Abstract 19 Industrial networks pose unique challenges in realizing a 20 communication substrate on the shop floor. Such challenges are due 21 to strict Quality of Service (QoS) requirements, a wide range of 22 protocols for data exchange, and highly heterogeneous network 23 infrastructures. In this regard, this document proposes a framework 24 for QoS-enabled semantic routing in industrial networks. Such a 25 framework aims at providing loosely-coupled, asynchronous 26 communications, fine-grained traffic management (delivery semantics 27 and flow priorities), and in-network traffic optimization. 29 Discussion Venues 31 This note is to be removed before publishing as an RFC. 33 Source for this draft and an issue tracker can be found at 34 https://github.com/fglmtt/draft-bellavista-semantic-sdn-mom. 36 Status of This Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at https://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on 4 September 2022. 53 Copyright Notice 55 Copyright (c) 2022 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 60 license-info) in effect on the date of publication of this document. 61 Please review these documents carefully, as they describe your rights 62 and restrictions with respect to this document. Code Components 63 extracted from this document must include Revised BSD License text as 64 described in Section 4.e of the Trust Legal Provisions and are 65 provided without warranty as described in the Revised BSD License. 67 Table of Contents 69 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 70 2. Target Scenario . . . . . . . . . . . . . . . . . . . . . . . 4 71 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 6 72 4. Principles and Design Guidelines . . . . . . . . . . . . . . 7 73 5. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 9 74 6. Conventions and Definitions . . . . . . . . . . . . . . . . . 12 75 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 76 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 77 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 78 9.1. Normative References . . . . . . . . . . . . . . . . . . 13 79 9.2. Informative References . . . . . . . . . . . . . . . . . 13 80 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 14 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 83 1. Introduction 85 This Internet Draft defines a framework for Quality of Service (QoS)- 86 enabled semantic routing in industrial networks. The term "semantic 87 routing" refers to a form of routing based on additional semantics 88 other than mere IP addresses 89 [I-D.draft-farrel-irtf-introduction-to-semantic-routing-03]. Along 90 with the semantics carried in packet headers, such routing may also 91 depend on policy coded in, configured at, or signaled to network 92 devices. A network device is an element that receives/transmits 93 packets and performs network functions on them, such as forwarding, 94 dropping, filtering, and packet header (or payload) manipulation, 95 among others. Network devices may operate in, above, and below the 96 network layer. 98 The framework described in this draft uses the overlay networking to 99 provide a semantic routing substrate that operates both at the 100 application and network level. 102 At the application level, the framework consists of Message-Oriented 103 Middleware (MOM) and Application Gateways (AGWs). The MOM allows 104 decoupling senders and receivers, sorts messages in topics of 105 interest, and provides delivery semantics (e.g., at most once, at 106 least once, and exactly once). The AGWs sit nearby industrial 107 machines that are not natively compliant with the protocols the 108 framework relies on. For example, some legacy industrial machines 109 may not even support IP-based communications. It is worth mentioning 110 that the typical lifetime of industrial equipment is 10 to 15 years 111 (even longer sometimes), and in many cases, the software cannot be 112 updated due to manufacturers' policy. Accordingly, AGWs translate 113 the plethora of (proprietary) protocols that coexist on the shop 114 floor towards the one(s) used by the framework. 116 At the network level, the framework combines two paradigms: Software- 117 Defined Networking (SDN) [RFC7426] and In-Network Processing (INP) 118 [ZILBERMAN2019], [PORTS2019]. Although the MOM enables critical 119 features in message dispatching, it does not control how packets flow 120 through network devices along routing paths. This is where SDN comes 121 in. Specifically, the SDN controller computes optimal routes to meet 122 the QoS requirements and configures network devices accordingly. The 123 term INP refers to executing end-host programs within network 124 devices. Such INP-enabled network devices operate at a line rate, 125 processing packets as they traverse them without increasing the 126 overall network load. Given that the SDN controller holds a network- 127 wide view, it also knows which network devices support INP and which 128 do not. The SDN controller may redirect flows towards target INP- 129 enabled network devices based on the processing functions they 130 provide. 132 The objectives that the framework targets are the following: 134 * Loosely-coupled, asynchronous communications; 136 * Fine-grained traffic management (delivery semantics and flow 137 priorities); 139 * In-network traffic optimization. 141 The remainder of this draft is structured as follows. First, 142 Section 2 details the target scenario. Then, Section 3 provides the 143 requirements of the target scenario. Lastly, Section 4 presents the 144 principles and design guidelines of the framework and Section 5 145 depicts its architecture. 147 2. Target Scenario 149 Traditionally, a shop floor includes industrial machines, 150 Programmable Logic Controllers (PLCs), and Human-Machine Interfaces 151 (HMIs). Typically, industrial machines are equipped with sensors and 152 actuators, PLCs control manufacturing processes, and human operators 153 interact with and receive feedback from industrial machines through 154 HMIs. In such legacy industrial networks, the message dispatching 155 was primarily oriented to monitor operational- and safety-related 156 machine parameters. 158 Nowadays, the shop floor has become more articulated due to the 159 advent of the Industrial Internet of Things (IIoT). On the one hand, 160 IIoT devices enable business-critical services (e.g., predictive 161 maintenance) cost-effectively. On the other hand, they dramatically 162 increase overall network traffic volume, infrastructure 163 heterogeneity, and cyber security threats. 165 The heterogeneity is not only about the industrial equipment itself 166 but also in how such equipment disseminates information. The 167 plethora of (proprietary) protocols that machines use to exchange 168 data makes machine-to-machine communications challenging. 170 Additionally, the shop floor may include dynamic industrial equipment 171 (e.g., automated guided vehicles) that communicate on the move. Such 172 dynamic equipment may abruptly migrate communications across 173 different access points according to the physical location at a given 174 time. 176 Therefore, modern industrial environments stress the network 177 infrastructure more than traditional ones, where network traffic was 178 fairly limited to mission-critical information generated by fixed 179 network equipment. 181 In fulfilling current industrial guidelines for cyber security (e.g., 182 IEC 62443 [IEC62443]), the industrial topology should consist of 183 several shop floor subnets and a control room subnet. Figure 1 184 depicts an industrial topology compliant with such guidelines. 186 Control Room Subnet 187 +---------------------------------------------------------------+ 188 | | 189 | +------------+ +------------+ +------------+ +------------+ | 190 | | SDN | | AGW | | MOM | | INP | | 191 | | Controller | | Controller | | Controller | | Controller | | 192 | +-----+------+ +-----+------+ +------+-----+ +------+-----+ | 193 | | | | | | 194 | +--------------+-------+-------+--------------+ | 195 | | | 196 | +---+---+ | 197 | | SGW | | 198 +---------------------------+---+---+---------------------------+ 199 | 200 ----------------+---------------+----------------+--------------- 201 | | 202 +-----------+---+---+----------+ +-----------+---+---+----------+ 203 | | SGW | | | | SGW | | 204 | +---+---+ | | +---+---+ | 205 | | | | | | 206 | +------------+-----------+ | | +----------+ | | 207 | | AGW | | | | AGW +-+--+------+ | 208 | +-+------+------+------+-+ | | +-+------+-+ | | | 209 | | | | | | | | | | | | 210 | +-+------+------+------+-+ | | +-+------+-+ +-+------+-+ | 211 | | Machines | | | | Machines | | Machines | | 212 | +------------------------+ | | +----------+ +----------+ | 213 | | | | 214 +------------------------------+ +------------------------------+ 215 Shop Floor Subnet 1 Shop Floor Subnet N 217 Figure 1: Target network topology 219 Note that: 221 * With "Machines", we refer to any shop floor entity (e.g., 222 industrial machines, IIoT devices, PLCs, and so on) doing 223 networking. This document makes no distinction among shop floor 224 entities because AGWs can normalize their outputs if needed; 226 * Each shop floor subnet may be provided with one or more AGWs, 227 depending if machines support the protocols used by the framework; 229 * Each subnet is provided with a Subnet Gateway (SGW), which is a 230 network device. Additional network devices may be placed between 231 different subnets as well as within subnets. 233 The network devices interconnecting the subnets form the industrial 234 network backbone. The outcome is a multihop multipath topology 235 providing point-to-point connections with differentiated performance. 237 The framework described in this document targets the scenario 238 depicted in Figure 1. The framework components (i.e., MOM, AGW, SDN, 239 and INP controllers) run within the control room subnet. Note that 240 also other services may run in the control room subnet along with 241 them. Typical examples are the Manufacturing Execution System (MES) 242 and the Enterprise Resource Planning (ERP). 244 3. Requirements 246 The transition from traditional to modern industrial environments 247 raised critical communications challenges exposed in Section 2. In 248 this regard, it is worth remarking that industrial machines typically 249 have long lifetimes (decades), high costs (millions of USD), and 250 restrictive manufacturers' policies in place (e.g., to prevent 251 firmware updates). Accordingly, the communications substrate should 252 face such challenges by fulfilling additional requirements. 254 First, non-mission-critical and mission-critical traffic should be 255 distinguished. Typically, non-mission-critical flows (e.g., 256 monitoring of vibrations) are more massive than mission-critical ones 257 (e.g., alerting human operators about dangerous events), thus the 258 former may easily take network resources at the expense of the 259 latter. This requires per-flow traffic management, ranging from flow 260 prioritization (mission-critical flows go first, then non-mission- 261 critical ones) to data aggregation and filtering to reduce the 262 traffic traversing the network. Since the industrial control 263 typically runs cyclically in millisecond level, the control traffic, 264 especially the mission-critical traffic, demands high QoS in terms of 265 latency, jitter, and extremely low packet loss ratio. 267 Second, the industrial communication demands high reliability. The 268 telecommunication equipment deployed in the Internet typically 269 guarantee the reliability to 99.99%. However, the industrial systems 270 need to be much more reliable, from 99.9999% to 99.99999%, in order 271 to reduce the downtime of the production line. It requires the 272 industrial network to equip extra measures to support it. 274 Third, machine-to-machine communications should be enabled 275 straightforwardly, notwithstanding the plethora of (proprietary) 276 dialects that coexist at the shop floor level, which enables the 277 interoperability of different shop floor devices. This requires 278 connectors to translate such dialects towards a common one and 279 metadata to express the semantics. Intermediate nodes may use 280 semantics to process packet payloads according to the information 281 they carry. For example, an intermediate node may average a given 282 number of consecutive temperature values (data aggregation) rather 283 than drop values of little application interest (data filtering). 285 Lastly, machines should keep communicating on the move without 286 affecting overall performance. For example, an automated guided 287 vehicle may move from a shop floor subnet to another. By doing so, 288 the vehicle changes the WiFi access point (i.e., SGW) used to access 289 the network. As a result, the flows sent out by such a vehicle need 290 to be rescheduled accordingly. This requires not only to reconfigure 291 network devices dynamically, but also to do so in compliance with 292 other flows already in place. 294 In this context, edge computing plays a crucial role in enabling the 295 design and implementation of novel distributed control functions with 296 parts that are hosted on the edge nodes located in the production 297 plant premises and close to the controlled sensors/actuators, 298 primarily to increase reliability and decrease latency. In the 299 following, we discuss a framework for QoS-Enabled Semantic Routing in 300 Industrial Networks capable of synchronizing several entities in a 301 simplified manner via a unique logical configuration interface 302 ("Northbound interface"). 304 4. Principles and Design Guidelines 306 Future industrial networks will be characterized by an unprecedented 307 degree of heterogeneity and complexity. Traditional solutions, 308 mainly based on the direct interconnection of machines one to each 309 other and machines towards the control room, cannot provide the 310 required degree of flexibility. This leads to exploring novel 311 solutions to manage the deluge of data generated by IIoT devices and 312 provide QoS-driven network (re)configuration. 314 By considering the momentum of MOM as an enabler of the Industry 4.0 315 vision, we believe it will become a pillar of future industrial 316 ecosystems. Although it enables critical features to facilitate 317 message dispatching independent from actual machine location, it does 318 not control how packets flow through middle network devices along the 319 routing path. In fact, once a message is sent from a broker to a 320 consumer (or vice versa, from a producer to a broker), the path the 321 message traverses is beyond the MOM's control. However, the ability 322 to dictate the behavior of middle network devices is essential to 323 satisfy stringent QoS requirements. This is where the SDN paradigm 324 comes in. 326 The SDN controller eases configuration and management of network 327 devices, which act as the (distributed) communication substrate 328 between the machines and the MOM. In addition, the SDN controller 329 provides network-wide abstractions to define and enforce fine-grained 330 network policies. 332 At the top level, the MOM identifies the destination nodes a message 333 should be dispatched, along with the delivery semantics (e.g., at 334 most once, at least once, or exactly once) to be applied. At the 335 bottom level, AGWs deployed close to machines act as intermediaries 336 between the machines (and the plethora of protocols they speak) and 337 the MOM. In the middle level, the SDN controller exploits its 338 network-wide view to (re)configure the network devices according to 339 the QoS requirements. 341 Based on the MOM-SDN interplay, network devices can be properly 342 configured: 344 * To select the best route towards the destination and forward 345 messages accordingly; 347 * To manage competing traffic flows in a coordinated manner, e.g., 348 to ensure prompt dispatching of mission-critical messages even if 349 at the expense of less critical messages; 351 * To enforce INP for traffic optimization, e.g., by merging 352 consecutive packets in a single one. 354 For example, by considering two traffic flows between the MOM broker 355 and a machine, proper routing table management allows to forward 356 traffic flows tagged as "mission-critical" via a large-bandwidth low- 357 latency path (if available). Besides, traffic flows tagged as "not- 358 urgent" may be delayed, where the magnitude of the imposed delay may 359 also depend on the current level of network saturation. Finally, an 360 INP-enabled network device may exploit the semantics about the 361 carried data to provide content-based message management. For 362 instance, it is possible to forward packets only if they satisfy a 363 given rule, e.g., if they carry temperature values greater than a 364 given threshold, or to apply functions to send pre-processed values, 365 e.g., sending only one packet with the average temperature resulting 366 from a series of received temperature values. Note that content- 367 based message management enables decisions on what is carried within 368 packet payloads rather than only on packet headers (mere forwarding). 369 However, since payload inspection and manipulation may introduce 370 additional delays, content-based message management should be 371 enforced as much as possible but without burdening mission-critical 372 traffic flows. 374 From a functional point of view, the INP level sits atop the data 375 forwarding level. As in the case of SDN deployment, we do not argue 376 that all the network devices should be INP-enabled. Instead, we 377 promote a pragmatic approach where legacy and novel solutions 378 cooperate effectively. Since the SDN controller holds a network-wide 379 view, it knows which network devices offer INP and which do not. 380 Therefore, traffic can be optimally handled by maximizing INP (e.g., 381 routing of packets carrying values that can be averaged towards 382 network devices providing that aggregation function) while ensuring 383 QoS requirements. 385 5. Architecture 387 The proposed architecture, mostly working at the application layer, 388 adopts the typical SDN approach by identifying two main areas: 389 Control Plane and Data Plane. In the Control Plane, the following 390 components are deployed: the MOM controller, interacting with the MOM 391 broker; the In-Network Processing (INP) controller, managing the INP 392 units; the SDN controller, controlling network elements; and the 393 Gateway controller, managing the many application gateways deployed 394 in the environment. The Data Plane consists of the implementation of 395 the MOM, the INP units, the SDN-enabled network elements, and the 396 Gateway components. 398 PROTO E 399 +-------------+-------------+---------------------+ NORTHBOUND 400 | | | | IFACE 401 v v v v 402 +-----+-----+ +-----+-----+ +-----+-----+ +-----+-----+ 403 | GATEWAY | | SDN | | INP | | MOM | CONTROL 404 |CONTROLLER | |CONTROLLER | |CONTROLLER | |CONTROLLER | PLANE 405 +-----+-----+ +-----+-----+ +-----+-----+ +-----+-----+ 406 ^ ^ ^ ^ 407 |PROTO A |PROTO B |PROTO C PROTO D| SOUTHBOUND 408 | | | | IFACES 409 v | v v 410 +-----+-----+ | +-----+-----+ +-----+-----+ 411 | GATEWAY | | | INP UNIT | | MOM | 412 +-----------+ v +-----------+ +-----------+ DATA 413 +-------------------+-----------------------------------------+ PLANE 414 | SDN | 415 +-------------------------------------------------------------+ 417 Figure 2: Functional/layered view of the SDN-MOM distributed 418 architecture. 420 Each component has different duties and responsibilities: 422 * The MOM Controller is demanded to control and re-route the traffic 423 flowing into the MOM topics. It uses information coming from the 424 northbound interface and returns back control messages for the SDN 425 controller. It also performs decisions based on the message 426 headers and on the information received from the SDN Controller 427 and the Gateway Controller. The messages can be forwarded to a 428 specific topic, duplicated among different topics, or consumed and 429 pulled out from the flow. At the same time, the MOM Controller 430 issues information that will be used from the SDN controller to 431 correctly configure the SDN devices for achieving the desired 432 level of QoS on the specific output flow. 434 * The Message-Oriented Middleware (MOM) is one of the core pieces of 435 our infrastructure. It is the logical single point of 436 communication between several firm sectors. It contains topics 437 written by the Gateways and can be read by multiple other 438 Gateways, based on the plant communication requirements. The MOM 439 is responsible for guaranteeing differentiated QoS policies with 440 different semantics. Typically, the at-most-once semantic can be 441 used for best-effort machinery traffic. Otherwise, at-least-once 442 semantic can be used for monitoring mission-critical assets and 443 for controlling traffic. Moreover, some messages can be sent with 444 high priority, guarantying differentiated traffic management and 445 avoiding congestion. 447 * The SDN Controller centralizes network intelligence in a separate 448 component, disassociating the packet forwarding process from the 449 routing processes. The SDN Control Plane consists of one or more 450 controllers that are considered as the brain of the network, where 451 all intelligence is embedded. The SDN Controller configures the 452 network resources. In our infrastructure, the SDN Controller has 453 full knowledge of the network and the paths, guarantying a fine- 454 grained ruling of the traffic coming from the Gateways. 455 Differentiated policies can be applied based on the content of the 456 messages, following the received northbound rules. The traffic 457 can be duplicated, aggregated, blocked, forwarded, and re-routed 458 on different data paths. 460 * The Gateway Controller emits control messages directed to the 461 Gateways of the infrastructure. It works in strict coordination 462 with the MOM Controller and SDN Controller, to avoid congestions 463 and to maintain topic abstractions coherent with the real machine 464 distribution. Its management duties comprehend: checking of the 465 state of all the gateways, which must be configured coherently 466 with the machine on which are acting; synchronization with SDN and 467 MOM controllers, that can send re-configuration messages to avoid 468 congestion. Practically, it can manage the header that is applied 469 from the Gateways to each packet, modify the priority of the 470 messages, and define levels of QoS applied directly to the data- 471 extraction phase. 473 * The Gateways duties comprehend the data gathering, the data 474 transformation to an internal MOM-specific representation, the 475 header addition, and the interconnection between the industrial 476 machinery world and the MOM topic-centric world. In industrial 477 scenarios, it is common to have machines that use different 478 languages and protocols for data exporting and representation 479 (e.g. Modbus, Profibus, OPC UA, OMG DDS, EtherCAT). For this 480 purpose, the Gateways can be specialized with ad-hoc libraries and 481 push or pull strategies based on the specific machinery from which 482 to gather information. Moreover, the QoS can be managed directly 483 at this level, avoiding high useless throughput when the plant is 484 working in a normal condition. 486 * The INP Controller is demanded to control the INP elements of the 487 platform. Its duties comprehend synchronization between INP 488 units, deployment of the correct function for the specific INP 489 unit input flow, management of the QoS on the INP components. 491 * The INP Units are hardware/software components demanded to reduce 492 or pre-process the data in ingress. The flows are manipulated 493 accordingly to INP Controller rules and the typical map/reduce 494 functions can be applied in the flow. 496 Figure 2 depicts a schematic of the entire infrastructure. Dashed 497 paths between controller entities in the control plane (Protocol E), 498 and between control and data planes represent the management/ 499 configuration data exchanges that are logically separate from data 500 flows (Protocols A, B, C, D). Data flows start from the Gateways 501 (connected to the machinery via the machine-specific protocols) and 502 are sent through the SDN Component, which traverses the entire 503 platform. 505 The proposed platform can be seen as an integration of several 506 software architectures in a unique system capable of interacting with 507 them in a uniform and controlled way. In this draft, we omit our 508 specific implementation of each protocol, and we ask the RFC 509 community for possible implementations capable of satisfying each 510 step necessities and requirements. Although certain interfaces can 511 be easily implemented using standard de facto protocols, for 512 instance, Protocol B can be found in to Open Networking Foundation, 513 "OpenFlow Switch Specification", Version 1.5.1, October 2015, 514 https://opennetworking.org/wp-content/uploads/2014/10/openflow- 515 switch-v1.5.1.pdf (https://opennetworking.org/wp- 516 content/uploads/2014/10/openflow-switch-v1.5.1.pdf), and Protocol C 517 can be The P4 Language Consortium, "P416 Language Specification", 518 Version 1.2.1, June 2020, https://p4.org/p4-spec/docs/ 519 P4-16-v1.2.1.html (https://p4.org/p4-spec/docs/P4-16-v1.2.1.html), 520 the others interfaces remain open issues and must be implemented as 521 ad-hoc solutions. 523 6. Conventions and Definitions 525 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 526 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 527 "OPTIONAL" in this document are to be interpreted as described in 528 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 529 capitals, as shown here. 531 7. Security Considerations 533 While this Internet Draft is not primarily focused on addressing 534 security issues, it is of paramount importance to provide some 535 security considerations. In particular note that since the proposed 536 solution should be adopted in industrial environments, possible 537 security threats could cause not only issues related to the IT 538 domain, such as service unavailability and data leak, but also to the 539 OT domain, thus also including potential impact to the safety of 540 human operators. To this purpose, we consider of paramount 541 importance (and push for) the adoption of best practices in terms of 542 security and safety of industrial environments and thus we advise the 543 application of the IEC 62443 family standard as a prerequisite for 544 the deployment of the proposed solution. In addition, by focusing on 545 the proposed solution we recognize that while it is suitable to 546 maximize the QoS of higher priority industrial applications, it 547 should not be achieved to the total detriment of lower priority 548 industrial applications, whose packets should be anyway delivered. 550 8. IANA Considerations 552 This document has no IANA actions. 554 9. References 555 9.1. Normative References 557 [I-D.draft-farrel-irtf-introduction-to-semantic-routing-03] 558 Farrel, A. and D. King, "An Introduction to Semantic 559 Routing", Work in Progress, Internet-Draft, draft-farrel- 560 irtf-introduction-to-semantic-routing-03, 22 January 2022, 561 . 564 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 565 Requirement Levels", BCP 14, RFC 2119, 566 DOI 10.17487/RFC2119, March 1997, 567 . 569 [RFC7426] Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S., 570 Hadi Salim, J., Meyer, D., and O. Koufopavlou, "Software- 571 Defined Networking (SDN): Layers and Architecture 572 Terminology", RFC 7426, DOI 10.17487/RFC7426, January 573 2015, . 575 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 576 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 577 May 2017, . 579 9.2. Informative References 581 [BELLAVISTA2018] 582 Bellavista, P., Dolci, A., and C. Giannelli, "MANET- 583 oriented SDN: Motivations, Challenges, and a Solution 584 Prototype", DOI 10.1109/wowmom.2018.8449805, 2018 IEEE 585 19th International Symposium on "A World of Wireless, 586 Mobile and Multimedia Networks" (WoWMoM), June 2018, 587 . 589 [BELLO2020] 590 Bello, L., Lombardo, A., Milardo, S., Patti, G., and M. 591 Reno, "Experimental Assessments and Analysis of an SDN 592 Framework to Integrate Mobility Management in Industrial 593 Wireless Sensor Networks", DOI 10.1109/tii.2020.2963846, 594 IEEE Transactions on Industrial Informatics Vol. 16, pp. 595 5586-5595, August 2020, 596 . 598 [IEC62443] International Electrotechnical Commission, "IEC 62443: 599 Industrial network and system security". 601 [KAUR2018] Kaur, K., Garg, S., Aujla, G., Kumar, N., Rodrigues, J., 602 and M. Guizani, "Edge Computing in the Industrial Internet 603 of Things Environment: Software-Defined-Networks-Based 604 Edge-Cloud Interplay", DOI 10.1109/mcom.2018.1700622, IEEE 605 Communications Magazine Vol. 56, pp. 44-51, February 2018, 606 . 608 [LI2018] Li, X., Li, D., Wan, J., Liu, C., and M. Imran, "Adaptive 609 Transmission Optimization in SDN-Based Industrial Internet 610 of Things With Edge Computing", 611 DOI 10.1109/jiot.2018.2797187, IEEE Internet of Things 612 Journal Vol. 5, pp. 1351-1360, June 2018, 613 . 615 [NATESHA2021] 616 V, N. and R. Guddeti, "Fog-Based Intelligent Machine 617 Malfunction Monitoring System for Industry 4.0", 618 DOI 10.1109/tii.2021.3056076, IEEE Transactions on 619 Industrial Informatics Vol. 17, pp. 7923-7932, December 620 2021, . 622 [PORTS2019] 623 Ports, D. and J. Nelson, "When Should The Network Be The 624 Computer?", DOI 10.1145/3317550.3321439, Proceedings of 625 the Workshop on Hot Topics in Operating Systems, May 2019, 626 . 628 [RFC5870] Mayrhofer, A. and C. Spanring, "A Uniform Resource 629 Identifier for Geographic Locations ('geo' URI)", 630 DOI 10.17487/rfc5870, RFC Editor report, June 2010, 631 . 633 [ZILBERMAN2019] 634 Zilberman, N., "In-Network Computing", 2019, 635 . 637 Acknowledgments 639 TODO acknowledge. 641 Authors' Addresses 643 Paolo Bellavista 644 University of Bologna 645 Email: paolo.bellavista@unibo.it 646 Luca Foschini 647 University of Bologna 648 Email: luca.foschini@unibo.it 650 Lorenzo Patera 651 University of Bologna 652 Email: lorenzo.patera@unibo.it 654 Mattia Fogli 655 University of Ferrara 656 Email: mattia.fogli@unife.it 658 Carlo Giannelli 659 University of Ferrara 660 Email: carlo.giannelli@unife.it 662 Cesare Stefanelli 663 University of Ferrara 664 Email: cesare.stefanelli@unife.it 666 David Zhe Lou 667 Huawei 668 Email: zhe.lou@huawei.com