Internet Area Working Group                                  C. Westphal
Internet-Draft                                              K. Makhijani
Intended status: Informational                            Futurewei, USA
Expires: 8 January 2023                                           K. Dev
                               Munster Technological University, Ireland
                                                             L. Foschini
                                            University of Bologna, Italy
                                                             7 July 2022

              OCN Use Cases for Industry control Networks


   This document present industrial networking use cases for Operations
   and Control Networks (OCN).  It is a companion document to the OCN
   reference model and the OCN problem statement and requirements
   document.  This document compiles a list of potential use cases where
   new industrial networking protocols could be beneficial.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 8 January 2023.

Copyright Notice

   Copyright (c) 2022 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

Westphal, et al.         Expires 8 January 2023                 [Page 1]

Internet-Draft                OCN Use Cases                    July 2022

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   3
   3.  Background and Framework  . . . . . . . . . . . . . . . . . .   4
   4.  Industrial Use Cases  . . . . . . . . . . . . . . . . . . . .   6
     4.1.  Protocol Convergence  . . . . . . . . . . . . . . . . . .   6
     4.2.  Self-Configuration of Industrial Networks . . . . . . . .   7
     4.3.  5G Private Networks . . . . . . . . . . . . . . . . . . .   8
     4.4.  IIoT  . . . . . . . . . . . . . . . . . . . . . . . . . .   8
     4.5.  Large Volume Application  . . . . . . . . . . . . . . . .   9
     4.6.  Remote Control  . . . . . . . . . . . . . . . . . . . . .  10
     4.7.  Determinism . . . . . . . . . . . . . . . . . . . . . . .  10
     4.8.  Industry 5.0  . . . . . . . . . . . . . . . . . . . . . .  11
     4.9.  Virtual PLC . . . . . . . . . . . . . . . . . . . . . . .  11
     4.10. Simplification of OT/IT Integration . . . . . . . . . . .  12
     4.11. Smart Contract  . . . . . . . . . . . . . . . . . . . . .  13
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .  14
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  14
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  14
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .  14
     7.2.  Informative References  . . . . . . . . . . . . . . . . .  14
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  15
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  15

1.  Introduction

   This document present the OCN Industrial Use Cases.  OCN stands for
   Operations and Control Networks.  It is believed that current network
   protocols are not flexible enough to allow deployment in industrial

   Industrial networks have a specific set of requirements and existing
   solutions and technologies.  It is however expected that the
   deployment of 5G and of solutions to extend the WAN into distributed
   and potentially remote or hard to reach locations would dramatically
   alter the way these networks are deployed, managed and operated.

   In particular, it is expected that these networks would interconnect
   a wider range of networks potentially at a global scale; would
   interface and peer with a wider number of potential networks,
   including the global Internet; and would coalesce around a unified
   set of protocols, both to commoditize and reduce the cost of the
   industrial network infrastructure, and to offer interconnection with
   a wider set of networks over these unified protocols.

Westphal, et al.         Expires 8 January 2023                 [Page 2]

Internet-Draft                OCN Use Cases                    July 2022

   In this document, we first give a quick background on OCN and
   industrial networks, and then present use cases where new industrial
   network protocols would potentially bring new features and new

   These use cases could potentially be solved with current technology,
   or are active areas of investigation.  However we believe that
   eventually, some unified set of protocols would be useful that
   supports these use cases.  While we make no proposal for such
   protocol, we believe it would be of value to the community to seek to
   design such protocols.

2.  Conventions and Definitions

   We provide some definitions and acronyms that are relevant to this

   Industrial Control Network:  Industrial control networks are the
      interconnection of equipment used to operate, control, or monitor
      machines in the industry environment.  It involves different
      levels of communications between field bus devices, digital
      controllers, and software applications.

   Industry Automation:  Mechanisms that enable the machine to machine
      communication by use of technologies that enable automatic control
      and operation of industrial devices and processes leading to
      minimizing human intervention.

   Control Loop:  Control loops are part of process control systems in
      with desired process response is provided as an input to the
      controller, which performs the corresponding action (using
      actuators) and reads the output values.  Since no error correction
      is performed, these are called open control loops.

   Feedback Control Loop:  Feedback control loop is a system in which
      the output of a control system is continuously measured and
      compared to the input reference value.  The controller uses any
      deviation from the input value to adjust the output value for the
      desired response.  Since there is a feedback of error signal to
      the input, these are called closed control loops.

   Programmable logic controllers (PLC):  Industrial computers/servers
      to control manufacturing processes such as assembly lines.

   Supervisory Control and Data Acquisition (SCADA):  Software System to
      control industrial processes and collect and manage data.

   Distributed Control Systems (DCS):  Systems of sensors and

Westphal, et al.         Expires 8 January 2023                 [Page 3]

Internet-Draft                OCN Use Cases                    July 2022

      controllers that are distributed throughout a plant.

   Fieldbus Devices:  A device which is installed on the field (e.g.,
      solar farm, energy grid, autonomous vehicle).  Operational
      Technology field devices include valves, transmitters, switches,
      actuators, etc.

   Operations and Control Networks (OCN):  A network that supports all
      the capabilities necessary to accomplish a process or control
      command execution on actuators for the desired effect prescribed
      by the controllers based on continuous inputs from the sensory
      data and application requests.

3.  Background and Framework

   Traditional communication networks facilitate the data communication
   between multiple devices and peripherals.  With the evolution of
   devices and systems such as Internet of Things (IoT) and cyber-
   physical system (CPS), the characteristics of a network has undergone
   great changes.  In order to accommodate IoT and CPS, Industrial
   Communication Networks were introduced that could handle data
   integrity and real-time control for large installations in harsh
   environments.  The purpose of these networks is to connect sensors
   (devices that monitor some parameter at a site), actuators (devices
   that perform an action in the physical world), controllers and other
   elements that require some specific network services.

   In Industrial applications, these networks include ControlNet,
   Modbus, DeviceNet, Ethernet, Profinet and so on.  They form a
   connection among PCs, controllers, and field devices which is
   difficult to do with traditional communication networks.

   Industrial Ethernet is used extensively which is part of industrial
   automation, but with the advent of 5G and mMTC, it is expected that
   industrial networks would expand to a global reach.  This creates new
   constraints to meet the real-time operational needs.  These networks
   to support increasingly large number of devices with a wide range of
   standards and policies.  Furthermore, the factory system should offer
   solutions with great reliability, efficiency, and fast or even
   deterministic response times.

   The OCN problem statement we consider stems from [OCN-PS].

   We consider here industrial systems and networks, and they have a
   wide range of applications.  As a consequence, they operate in a wide
   range of conditions as well, which poses a challenge to operate and
   manage these networks.  The level of required connectivity will vary
   between devices within a network, and between the applications of the

Westphal, et al.         Expires 8 January 2023                 [Page 4]

Internet-Draft                OCN Use Cases                    July 2022

   network within an industry.  A manufacturing plant may have remotely
   controlled robots that perform assembly of a product, which have a
   much lower latency requirement than, say, a solar farm.

   For Industry control systems, there are different types of end-points
   and different types of traffic in between.  Some data traffic
   essentially convey instructions that need to be delivered within a
   specific time to perform a task at a machine or equipment.  Some may
   have more elastic latency requirements.  Some interactions between
   two end-points may be atomic, while some may require to convey some
   contect, or to maintain some state either within the network or at
   one or both of the end-points.

   The end-points in such systems can be either a controlling entity,
   sensors or actuators.  Sensors and actuators are assumed to not
   perform decision making tasks.  The controller has those

   The packets delivered from the controller are the actionable
   instructions to actuating device.  They may fit into a single packet,
   or be part of a data stream.  Many IoT application would have smaller
   packets, and therefore require consideration of packet overhead.
   Some other applications may require stream, for instance in case of
   videosurveillance of industrial operations.

   We briefly recall the main components of the OCN framework (for more
   details, see [OCN-RM]).

   An OCN is a network used to connect three basic types of functional
   devices - actuators, sensors and controllers.  They are well-known in
   the industry control systems (ICS) and are generalized to include all
   kinds of OCN scenarios.  The sensors and the actuators are associated
   with physical, logical, or digital entities that can be observed,
   monitored, or caused to move or change.  An OCN connects field
   devices, with the controllers and associates them for the exchange of
   data to trigger and monitor changes to achieve desired effect.

   The OCN connects these elements to support the services that enable
   the deployment of an industrial network, including providing some
   guarantees for certain type of services, some reliability, or some
   security.  Indeed, an industrial application may have strict latency
   requirements, for instance to control remotely the operation of some
   machinery.  It may also have some reliability requirement, as any
   down time may impact the bottom line of the industrial application it
   supports; and it should be robust to some attempts to disrupt the
   production from adversary entities.  Privacy may be a requirement as

Westphal, et al.         Expires 8 January 2023                 [Page 5]

Internet-Draft                OCN Use Cases                    July 2022

   The OCN framework is not limited to industrial networks.  Smart Grid
   or Self-Driving Cars for instance could be areas of application.  Any
   network that supports sensors, actuators and controllers is a target
   for deployment of such network.  We focus here on the use cases in
   the industrial/manufacturing sector, as it is expected that most
   machine-to-machine deployments would occur in the near future.

4.  Industrial Use Cases

   This section lists some of the Use Cases we anticipate for OCN.  This
   list is not exhaustive, and some of the use cases may be supported
   using current technologies.  We believe however that the superset of
   these use cases would provide basis for establishing a set of
   requirements for OCNs in the future.  This list is open for

4.1.  Protocol Convergence

   Currently, a hodgepodge of protocols are used in Industrial networks.
   We mentioned ControlNet, Modbus, DeviceNet, Ethernet, Profinet above.
   It is detrimental to the industry to have many protocols that cannot
   easily interoperate and have different support for different

   To reach a critical mass and to decrease the unitary cost of a device
   through economies of scale, we believe there is a need to unify these
   protocols into one common protocol.  We need a glue to connect these
   different networks together, similary to the way that the Internet
   became successful once a common narrow waist was defined and

   One special case is that of the field bus convergence protocol.
   Field bus are typically serial devices with limited range.

   A complex automated industrial system has typically a hierarchical
   structure, denoted distributed control system (DCS).  The top of the
   hierarchy for production management is connected to a control level
   of Programmable Logic Controllers (PLCs).  This is typically done via
   Ethernet.  The Fieldbus then links the PLCs to the control level of
   the components, namely sensors, actuators, switches, etc.  The
   fieldbus is therefore time-critical.  Fieldbuses are currently
   deployed over Industrial Ethernet, that is the use of Ethernet in an
   industrial environment that supports determinism and real-time

   Protocols for Industrial Ethernet include EtherCAT, EtherNet/IP,
   MQQT, etc.  Most of these protocols are at layer 2.  Translating

Westphal, et al.         Expires 8 January 2023                 [Page 6]

Internet-Draft                OCN Use Cases                    July 2022

   protocols to interoperate as well as to extend the range beyond the
   LAN would require new layer 3 protocols to connect the sensors,
   actuators and controllers in a more universal manner.

   In the OCN reference model, this use case connects sensor points
   (SPs), actuation points (APs) and controller points (CPs) using a
   unified OCN communication interface, to support delivery of OCN
   message of multiple types (in-time, on-time, bounded latency,
   periodic, etc.) as required by the underlying protocol that the OCN
   is emulating and/or replacing.

4.2.  Self-Configuration of Industrial Networks

   Adding new device in a distributed network, where the facilities have
   a large footprint, needs to be supported in the OCN.  Bootstrapping
   is a significant use case for a network that orchestrate and
   coordinates between a large number of sensors, actuators and

   Further, an OCN is a potentially large collection of devices that may
   be constrained in some way.  This means that the configuration of new
   field devices needs to be done in a scalable manner yet without
   burdening the devices with too many omputational steps (say, crypto
   computations), large exchange of data (say, firmware uploads) or
   other similar considerations.

   The deployment of such a network requires that the devices may be
   added to the network in a simple model, or removed from the network,
   or updated or modified, in a scalable manner.

   The OCN protocol need to support some form of authentication for new
   devices, or to have the ability to filter the data from devices
   (including field devices) so as to remove unwanted packets or to
   refuse transmission of data from unknown devices.  The data from the
   devices can be equipped with some authentication tokens or
   certificates that can be verified in the OCN.

   Some of this use case may be covered in the IETF IoTOPS, that deals
   with networked devices with a limited user interface and deployed in
   large numbers.  This could apply to some controllers, actuators and
   sensors in an OCN.  However, the indutrial networks have specific
   requirements to be considered here.

Westphal, et al.         Expires 8 January 2023                 [Page 7]

Internet-Draft                OCN Use Cases                    July 2022

   This pertains to the bootstrapping of an OCN, where the number of
   Actuation Points (APs), Sensor Points (SPs) and controller points
   (CPs) is potentially large and cannot be configured manually.  Some
   of the message types to be supported include asynchronous messages
   and periodic message for pushing firmware updates or checking the
   liveliness of a field device (AP, SP or CP).

4.3.  5G Private Networks

   One key aspect of 5G is to enable massive machine-to-machine (massive
   Machine-Type Communication - mMTC) over 5G private network or 5G
   campus networks.  This allows a large number of devices in
   distributed domains to connect together into a single industrial

   Private network can connect devices that could not be reached
   beforehand with a combination of wireless connectivity, WAN
   connectivity, and cloud connectivity.

   This allows to connecting devices at a much larger scale than current
   wifi deployments, for instance.  In the extreme, the whole industrial
   network could be connected into one single network domain where all
   the devices are reachable.

   Once consequence of a uniform network deployment would be to deploy
   networks - and devices within that network- using a single standard
   technology, rather than every industry creating their own
   idiosyncratic solution.

   The OCN interface in this use case has a much larger footprint, which
   requires care to support certain types of OCN messages (in particular
   in-time or bounded latency messages) due to the potential physical
   distance between the CP and the APs/SPs.

4.4.  IIoT

   One specific case of industrial OCN is that of connecting IoT
   devices.  The sensors and to some extent, the actuators, may have
   limited networking capability, due to for instance power constraints
   (due to battery-powered, or solar power devices).

   Constrained devices in an industrial OCN require specific
   considerations.  If the bandwidth of the link that connect to the
   devices is limited, the OCN protocol to exchange data should be
   designed carefully to minimize the overhead tax of the protocols.

Westphal, et al.         Expires 8 January 2023                 [Page 8]

Internet-Draft                OCN Use Cases                    July 2022

   Minimizing the protocol overhead may require to use flexible
   addressing scheme so that devices in a bandwidth constrained
   environment use shorter addresses than devices with plenty of
   bandwidth available.  Similarly, devices that transmit small amount
   of data should also be careful to not use very long pacekt headers.
   Of course, such addressing scheme still needs to provide some
   reachability throughout the OCN domain, and potentially globally.
   The protocol overhead in OCN should be such that it operates in an
   efficient regime.

   The OCN communication interface should therefore take into account
   the limits and constraints of the APs and SPs.

4.5.  Large Volume Application

   The opposite side of the coin of the previous use case is that of
   industrial networks that carry extremely large volume of

   For instance, some processes may require to extract a lot of
   information for continuous quality control.  This could be composed
   of some data from sensors, some measurement data, some video stream
   extracted from a monitoring camera where product defects can be
   identified using image processing.

   Other use case that generate large volume application would be the
   creation of a virtual environment that replicate off-site the
   conditions of the industrial facility, so that an operator can
   observe - or even participate within - that environment.  Such an AR/
   VR use case would require a large amount of data to be transmitted
   from the industrial facility to the location of the operator.

   Many pieces of equipment in an industrial environment also require
   continuous telemetry to monitor the functioning of the industrial
   facility, and potentially to identify conditions that may lead to
   failure ahead of time.  This also requires the transmition of a
   continuos stream of data that could encompass many different
   dimensions, as well as the data processing functions to identify the
   signature of a potential failure (or whatever other use is applied to
   this data).

   OCN therefore may require to transmit large amount of volumetric
   data.  Techniques to support the transmission of large volume of data
   (in particular, proper transport protocols) are required to support
   this use case.

Westphal, et al.         Expires 8 January 2023                 [Page 9]

Internet-Draft                OCN Use Cases                    July 2022

4.6.  Remote Control

   More and more industrial applications rely on controlling machinery
   from afar.  Among the reasons for this use is to consolidate the
   control of several facilities into one location; to control
   facilities that are in hazardous or sterile environment.  For
   instance oil extraction, refineries, mining industries are highly
   dangerous industries.

   We envision the deployment of networks for the remote control of the
   equipment in such environment to ensure safer procedures.  Remote
   control tools and robots can conduct the tasks that are risky for
   human beings.  The OCN network to support this use case would need to
   meet some stringent availability requirements, as well as some
   latency (corresponding to the eventual industrial application).

   Remote control is also a use case for vehicular network and remote
   driving, described in [OCN-remote-driving].

   With respect to the reference model, this entails support of bounded
   latency, in-time, on-time message types as well as support of
   reliability requirements on the OCN network itself.

4.7.  Determinism

   Industrial applications often have requirements that cannot be
   provided by best-effort networks.  As a result, some specialized
   protocols have been designed to provide performance guarantees beyond
   best-effort (BE).

   IEEE 802.1 Time-Sensitive Networking (TSN) builds on top of Ethernet
   to provide reserved shares of bandwidth in a sub-network.  However,
   there is a need to extend beyond Ethernet and still provide these
   same stringent guarantees across wider interconnected domains.
   [DetNet-TSN] extend this service to DetNet IP domains.

   For the case of IIoT, [I-D.irtf-coinrg-use-cases] suggests leveraging
   in-network computation.  The idea is that by bringing computation
   closer to the end devices, more stringent delay requirements can be
   achieved.  However, this requires re-architecting the network to
   support computations within the network.

   OCN requires stringent time constraints in many industrial
   applications.  The operations of an actuator need to be executed with
   fine grained time accuracy.  The OCN may extend beyond a domain of
   limited scope.  THe controller may be in a different site, for
   practical or for safety reasons, or due to virtualization objectives
   (see the vPLC use case for instance).

Westphal, et al.         Expires 8 January 2023                [Page 10]

Internet-Draft                OCN Use Cases                    July 2022

   In the reference model, this is captured by the in-time, on-time and
   bounded latency message types to be supported by an OCN.

4.8.  Industry 5.0

   Industry 5.0 is defined as the next phase of industrial production,
   after Industry 1.0 (the Industrial revolution of the 1800s with steam
   power), 2.0 (the adoption of electricy and of division of labor in
   the early 1900s), 3.0 (the appearance of electronics in production
   environment in the 1970s), 4.0 (smart manufacturing, in the 2000s).
   Industry 5.0 supports mass personalization of the production output.
   In this framework, collaborative robots (cobots) also communicate
   with humans to enable personalizable autonomous manufacturing.

   To achieve this, the production requires to be integrated with
   variations from product to product.  These changes need to be shared
   with the production line so as to integrate them within the product.
   The production line is the actuator, the controllers store the
   specificity of each produced item (say, a medical device that is
   specific to its user) and each specifications need to be shared
   across the OCN to each of the steps of the production line.

   This use case requires APs to be dynamically configured and
   potentially updated between producing consecutive items, and support
   for bounded-latency message type would reduce the downtime and
   increase the productivity of the Industry 5.0 production facility.

4.9.  Virtual PLC

   Many current industrial applications run over Programmable Logic
   Controlers (PLCs).  These are the basic building blocks of
   automation, and control sensors and actuators on factory floors.
   PLCs are everywhere, and perform trasks such as motion control for
   robots, or smart manufacturing automoation.

   There is a wide range of traditional PLCs, depending on size, type
   and function.  Size range from nano (with less than 15 I/O points) to
   large (with over 512 I/O).  As automation grows and becomes more
   dynamic, factory floors will need more and more PLCs with better
   performance, more flexibility and more I/Os.

   For this purpose, it is suggested to virtualize the PLCs and to
   leverage the benefits (in terms of elasticity and scale) of
   virtualization for PLCs.

Westphal, et al.         Expires 8 January 2023                [Page 11]

Internet-Draft                OCN Use Cases                    July 2022

   [PLC] defines virtualized PLCs as follows: "Virtualized PLC is a
   hardware-agnostic abstraction of the control unit and memory
   functions of a PLC.  It is hardware- independent and still needs an
   interface to communicate with the I/O modules."

   There are related trends to virtualized PLCs, such as the
   virtualization of HMI, SCADA MES, and other OT equipment, with the
   purpose of using general purpose hardware in a scalable manner; and
   to integrate higher lever functions that require more processing

   The benefits of virtual PLCs are many: it allows to leverage more
   sophisticated compute and storage and virtualization technologies.
   It integrates multiple PLCs operations on one platform, removing some
   superfulous movement of data; it allows for tighter application
   integration; it allows to leverage better edge support; and it frees
   up some physical space on the factory floor as the control units
   could be remote.

   Some instantiation of virtual PLC would require bettern network
   support.  The virtual PLC can be separated from the hardware, using
   some abstracted interface.  The Control Unit can be then placed
   across an OCN network, provided that it supports this placement away
   from the actuator.

   The network needs to preserve the zone security and safety of
   operations, and to support timeliness of the delivery as required by
   the application of the PLC (the control unit and its related

   For this use case, the network would provide a common interface
   between the device and the vPLC, as well as a unified converged
   fabric for all types of end-point.  The OCN between the vPLC and the
   APs/SPs needs to support in-time, on-time, periodic, synchronous
   message types.

4.10.  Simplification of OT/IT Integration

   Industrial networks have multiple devices in a specific location,
   where changes are relatively rare.  Many of them are wired devices
   from a network point of view, where direct process control loops are
   the more important aspect.

   Security is often achieved by separation, and in particular by
   separating the OT infrastructure from the IT.  The control loops
   oftern require deterministic network behavior.

Westphal, et al.         Expires 8 January 2023                [Page 12]

Internet-Draft                OCN Use Cases                    July 2022

   This creates some challenges, in particular to deal with the
   heterogeneity of industry protocols.  There are more than 100
   protocols, where the controller sits behind one protocol and control
   devices; stateful gateways are often required to translate in between

   This also hinders automation: the network is "engineered" to support
   a set of devices, and makes changes in the scale challenging.

   One use case of OCN would be to simplify the integration of OT and IT
   and to allow to run industrial (process control) technologies over

   There are structural differences in addressing between IP and
   industrial protocols.  IP offers a fixed number of bytes that
   identify a node.  Industrial protocols in different process control
   zones have different address spaces.  They typically don't have a
   network layer, but are scoped within a LAN.  Protocol format
   conversions are possible and may happen on the fly: devices of one
   protocol often connect to controller of other protocols.

   To enable a unified and simplied industrial network, we would need a
   comon network format that is friendly to both OT and IT applications.
   This needs to take into account that typical actuator and sensor data
   is often small, and could require either header compression or a
   flexible address structure.

   A network layer would need to be defined, especially as it pertains
   to extending this use case to support virtualization of the
   controllers (vPLC, as in the previous use case).

4.11.  Smart Contract

   Devices in an OCN may need to support some operations that are
   specified by the controller under the form of a smart contract.  For
   instance, some tasks may need to be specified by the controller as a
   function to be deployed in the field devices under the proper
   contract terms.

   The OCN needs to support mechanisms to propagate such smart contract
   (which may be programs or instruction sets, or just some
   authenticated information to share between the devices) and to
   validate them throughout the OCN network.

   This may relate to the configuration use case as well, since the
   contract may be to set up the device, for instance by specifying the
   credentials required for authentication and trust, and by setting up
   what type of function it will support.

Westphal, et al.         Expires 8 January 2023                [Page 13]

Internet-Draft                OCN Use Cases                    July 2022

   Smart contracts may require as well some abstractions to be
   validated, either within the OCN or at the edge of the OCN, and
   either in a distributed manner or within a specified control point.

5.  Security Considerations

   OCN may have security implications to discuss in subsequent

6.  IANA Considerations

   This document has no IANA actions.

7.  References

7.1.  Normative References

              Kunze, I., Wehrle, K., Trossen, D., Montpetit, M., Foy, X.
              D., Griffin, D., and M. Rio, "Use Cases for In-Network
              Computing", Work in Progress, Internet-Draft, draft-irtf-
              coinrg-use-cases-02, 7 March 2022,

7.2.  Informative References

              Varga, B., Farkas, J., Malis, A., and S. Bryant,
              "Deterministic Networking (DetNet) Data Plane: IP over
              IEEE 802.1 Time-Sensitive Networking (TSN)", RFC 9023, 8
              June 2021, <>.

   [OCN-PS]   "Problem Statement and Requirements for the Operation and
              Control Networks (OCNs)", n.d.,

              Dong, L., Li, R., and J. Hong, "Use Case of Remote Driving
              and its Network Requirements", Work in Progress, Internet-
              Draft, draft-dong-remote-driving-usecase-00, 27 June 2022,

   [OCN-RM]   "Operations and Control Networks - Reference Model and
              Taxonomy", n.d., <

Westphal, et al.         Expires 8 January 2023                [Page 14]

Internet-Draft                OCN Use Cases                    July 2022

   [PLC]      Makhijani, K. and L. Dong, "Virtualization of PLC in
              Industrial Networks - Problem Statement", Work in
              Progress, Internet-Draft, draft-km-iotops-iiot-frwk-02, 5
              March 2022, <


   TODO acknowledge.

Authors' Addresses

   Cedric Westphal
   Futurewei, USA

   Kiran Makhijani
   Futurewei, USA

   Kapal Dev
   Munster Technological University, Ireland

   Luca Foschini
   University of Bologna, Italy

Westphal, et al.         Expires 8 January 2023                [Page 15]