US20200028791A1 - Changing a time sensitive networking schedule implemented by a softswitch - Google Patents
Changing a time sensitive networking schedule implemented by a softswitch Download PDFInfo
- Publication number
- US20200028791A1 US20200028791A1 US16/586,391 US201916586391A US2020028791A1 US 20200028791 A1 US20200028791 A1 US 20200028791A1 US 201916586391 A US201916586391 A US 201916586391A US 2020028791 A1 US2020028791 A1 US 2020028791A1
- Authority
- US
- United States
- Prior art keywords
- softswitch
- compute node
- time sensitive
- sensitive networking
- schedule
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/50—Queue scheduling
- H04L47/56—Queue scheduling implementing delay-aware scheduling
- H04L47/564—Attaching a deadline to packets, e.g. earliest due date first
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/14—Network analysis or design
- H04L41/145—Network analysis or design involving simulating, designing, planning or modelling of a network
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L43/00—Arrangements for monitoring or testing data switching networks
- H04L43/50—Testing arrangements
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
- H04L47/24—Traffic characterised by specific attributes, e.g. priority or QoS
- H04L47/2416—Real-time traffic
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
- H04L47/28—Flow control; Congestion control in relation to timing considerations
- H04L47/283—Flow control; Congestion control in relation to timing considerations in response to processing delays, e.g. caused by jitter or round trip time [RTT]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L49/00—Packet switching elements
- H04L49/25—Routing or path finding in a switch fabric
- H04L49/253—Routing or path finding in a switch fabric using establishment or release of connections between ports
- H04L49/254—Centralised controller, i.e. arbitration or scheduling
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L49/00—Packet switching elements
- H04L49/70—Virtual switches
Definitions
- This disclosure relates generally to time sensitive networking and, more particularly, to changing a time sensitive networking schedule implemented by a softswitch.
- Time sensitive networks include network devices (also referred to herein as network elements) that interoperate to provide, among other things, time synchronization and packet scheduling to, for example, ensure one or more latency targets for packets sent from one network device to another network device are met. For example, industrial control applications may rely on such network latency target(s) being met to achieve proper operation of the industrial equipment being controlled.
- Time sensitive networks utilize a time sensitive networking schedule that is created based on the actual topology of the network and application latency requirements. The time sensitive networking schedule is implemented by the network devices. When the network topology changes and/or new applications are deployed in the time sensitive network, an updated time sensitive networking schedule is created and provided to the network devices for implementation.
- FIG. 1 is a block diagram of an example environment of use including an example central configuration controller and an example network node configurator to change a time sensitive networking schedule implemented by an example softswitch of a compute node in accordance with teachings of this disclosure.
- FIGS. 2-5 illustrate an example procedure performed by the example network node configurator of the example compute node of FIG. 1 to change the time sensitive networking schedule implemented by the softswitch of the compute node in accordance with teachings of this disclosure.
- FIG. 6 illustrates an example virtualized industrial function descriptor processed by the central configuration controller of FIG. 1 .
- FIG. 7 is a block diagram of an example implementation of the network node configurator of FIGS. 1-5 .
- FIG. 8 is a flowchart representative of example computer readable instructions that may be executed to implement the example central configuration controller of FIG. 1 .
- FIGS. 9-12 are flowcharts and pseudocode representative of example computer readable instructions that may be executed to implement the example network node configurator of FIGS. 1-5 and/or 7 .
- FIG. 15 is a block diagram of an example processor platform structured to execute the example computer readable instructions of FIGS. 8, 13 and/or 14 to implement the example central configuration controller of FIG. 1 .
- FIG. 16 is a block diagram of an example processor platform structured to execute the example computer readable instructions of FIGS. 9, 10, 11, 12, 13 and/or 14 to implement the example network node configurator of FIGS. 1-5 and/or 7 .
- connection references e.g., attached, coupled, connected, and joined are to be construed broadly and may include intermediate members between a collection of elements and relative movement between elements unless otherwise indicated. As such, connection references do not necessarily infer that two elements are directly connected and in fixed relation to each other.
- Descriptors “first,” “second,” “third,” etc. are used herein when identifying multiple elements or components which may be referred to separately. Unless otherwise specified or understood based on their context of use, such descriptors are not intended to impute any meaning of priority, physical order or arrangement in a list, or ordering in time but are merely used as labels for referring to multiple elements or components separately for ease of understanding the disclosed examples.
- the descriptor “first” may be used to refer to an element in the detailed description, while the same element may be referred to in a claim with a different descriptor such as “second” or “third.” In such instances, it should be understood that such descriptors are used merely for ease of referencing multiple elements or components.
- Example methods, apparatus, systems and articles of manufacture to change a time sensitive networking schedule implemented by a softswitch are disclosed herein.
- Example apparatus disclosed herein to change a time sensitive networking schedule implemented by a first softswitch on a compute node include an example network node configurator to deploy a second softswitch on the compute node based on a first configuration specification associated with the first softswitch.
- the example network node configurator is also to configure the second softswitch to implement an updated time sensitive networking schedule different from the time sensitive networking schedule implemented by the first softswitch.
- the example network node configurator is further to replace the first softswitch with the second softswitch in response to a determination that a first set of constraints is met for simulated network traffic processed by the second softswitch based on the updated time sensitive networking schedule.
- Such disclosed example apparatus also include an example traffic simulator to apply the simulated network traffic to the second softswitch.
- the first softswitch is to communicate with respective first ports (also referred to herein as port connections) of corresponding ones of a first set of virtual machines on the compute node to provide the first set of virtual machines with access to a network that implements time sensitive networking.
- the network node configurator is to: (i) connect the second softswitch to a network interface of the compute node, (ii) add respective second ports to corresponding ones of the first set of virtual machines, (iii) bind the respective second ports of the corresponding ones of the first set of virtual machines to the second softswitch, (iv) delete the respective first ports of the corresponding ones of the first set of virtual machines, and (v) delete the first softswitch from the compute node.
- the updated time sensitive networking schedule is to support deployment of a new virtual machine, which hosts a latency sensitive workload, to the compute node.
- the network node configurator is to: (i) connect a port of the new virtual machine to the second softswitch, (ii) configure the workload to operate in a test mode, (iii) monitor metrics associated with the simulated network traffic processed by the second softswitch, and (iv) configure the workload to operate in an operational mode after the determination that the first set of constraints is met for the simulated network traffic processed by the second softswitch based on the updated time sensitive networking schedule.
- the simulated network traffic includes first simulated network traffic associated with a first set of virtual machines on the compute node and second simulated network traffic associated with the new virtual machine.
- the first set of virtual machines may be in communication with the first softswitch, and the first simulated traffic may correspond to previously monitored network traffic obtained during operation of the first set of virtual machines.
- the network node configurator is to delete the second softswitch and the updated time sensitive networking schedule from the compute node in response to a determination that the first set of constraints is not met for the simulated network traffic processed by the second softswitch based on the updated time sensitive networking schedule.
- the second softswitch is associated with a second configuration specification, which is to correspond with the first configuration specification when the second softswitch is initially deployed on the compute node.
- the network node configurator in response to the determination that the first set of constraints is met for the simulated network traffic, is to adjust the second configuration of the second softswitch to satisfy at least one of a second set of constraints to be met for the simulated network traffic processed by the second softswitch based on the updated time sensitive networking schedule. For example, the network node configurator may iteratively adjust the second configuration of the second softswitch to satisfy other ones of the second set of constraints to be met for the simulated network traffic until a time limit is reached.
- example apparatus disclosed herein to change a time sensitive networking schedule implemented by a softswitch on a compute node include an example central user configurator to parse a virtualized industrial function descriptor corresponding to a virtualized workload to determine a set of parameters for an updated time sensitive networking schedule to be implemented by the softswitch. Such disclosed example apparatus also include an example central network configurator to determine the updated time sensitive networking schedule based on the set of parameters, and send the updated time sensitive networking schedule to the compute node.
- Some such disclosed example apparatus also include an example orchestrator to parse the virtualized industrial function descriptor to determine a virtual machine configuration specification for a virtual machine to deploy on the compute node to host the virtualized workload.
- the orchestrator is to send the virtual machine configuration specification to the compute node to cause the virtual machine to be deployed on the compute node.
- the orchestrator is further to delete the virtual machine from the compute node in response to a message from the compute node indicating a first set of constraints is not met by the updated time sensitive networking schedule.
- the central user configurator is to delete the updated time sensitive networking schedule in response to a message from the compute node indicating a first set of constraints is not met by the updated time sensitive networking schedule.
- the central user configurator is to determine whether the central network configurator supports generation of the updated time sensitive networking schedule based on a first one of the set of parameters. In some such examples, the central user configurator is to discard the first one of the set of parameters, or replace the first one of the set of parameters with a different parameter, when the central network configurator does not support generation of the updated time sensitive networking schedule based on the first one of the set of parameters.
- time sensitive networks include network elements that interoperate to provide, among other things, time synchronization and scheduling to, for example, ensure one or more latency targets for packets sent from one network element to another network element are met.
- network elements that implement a time sensitive network may be structured to implement a time sensitive networking (TSN) schedule in accordance with a defined standard, such as the Institute of Electrical and Electronics Engineers (IEEE) 802.1Qbv Standard, published on Mar. 18, 2016.
- IEEE 802.1Qbv Standard the Institute of Electrical and Electronics Engineers
- the TSN schedule specified by the IEEE 802.1Qbv Standard utilizes a gate structure and corresponding packet classifications to support strictly timed packet transmission slots.
- Interest in time sensitive networks is increasing due to their ability to ensure packet latency targets are met on an open standards-based network (as compared to a proprietary network).
- industrial control applications may rely on deterministic packet latency distributions with a known upper latency bound (e.g., such as 31.25 microseconds, or some other bound) for the isochronous, real-time network traffic generated by a given control function, such as a programmable logic controller (PLC), a motion controller, a numerical controller, etc.
- a known upper latency bound e.g., such as 31.25 microseconds, or some other bound
- PLC programmable logic controller
- motion controller e.g., a motion controller, a numerical controller, etc.
- a softswitch can be a virtual switch that is implemented by one or more virtual network functions (VNFs) that execute on a compute node, such as a server, a router, a cloud host, etc.
- VNFs virtual network functions
- softswitch virtual switch
- vSwitch vSwitch
- VIFs virtualized industrial functions
- Softswitches can be used in such examples to provide network connectivity between the VIF workloads on a compute node and the external equipment being controlled. Softswitches can also provide network connectivity between the VIF workloads on the compute node itself.
- the TSN schedule for a given time sensitive network is determined based on the actual topology of the network.
- an updated TSN schedule is created to accommodate that new VIF workload in the network.
- the updated TSN schedule is deployed to the TSN network endpoints.
- the TSN network endpoints include the TSN-enabled softswitch executing on that compute node to provide first-hop connectivity to the new VIF workload.
- Existing softswitch implementations may require stopping the softswitch, applying the updated TSN schedule to the softswitch, and then re-initializing/restarting the softswitch to have the updated TSN schedule take effect at the softswitch.
- example technical solutions disclosed herein utilize a duplicate softswitch (also referred to herein as a digital twin softswitch) to enable dynamic changing of a TSN schedule implemented by a softswitch without impacting the deterministic and real-time packet communications associated with existing workloads connected to the softswitch.
- a duplicate softswitch also referred to herein as a digital twin softswitch
- a change of the TSN schedule may be caused by a new workload being deployed in the time sensitive network.
- example technical solutions disclosed herein also utilize the duplicate softswitch (digital twin softswitch) to validate an updated TSN schedule in situ with the new workload being deployed, and can prevent deployment of the updated TSN schedule if a performance issue is detected.
- duplicate softswitch digital twin softswitch
- FIG. 1 a block diagram of an example central configuration controller 102 and an example network node configurator 138 structured to change a time sensitive networking schedule implemented by an example softswitch 106 of a compute node 104 in accordance with teachings of this disclosure is illustrated in FIG. 1 in the context of an example environment of use 100 .
- the compute node 104 corresponds to an edge compute node 104 deployed in an industrial environment (e.g., facility, plant, etc.) to execute workloads 108 , 110 , 112 to control example physical equipment 114 in the industrial environment.
- an industrial environment e.g., facility, plant, etc.
- the physical equipment can include a distributed control system (DCS), a physical programmable logic controller (PLC), a gateway, a robot, a tool, vision processing equipment, etc.
- DCS distributed control system
- PLC physical programmable logic controller
- the compute node 104 can be implemented by, for example, any appropriate computing device or combination of computing devices, such as a server in an edge cluster, an industrial computer, etc.
- the compute node 104 is implemented by a processor platform such as the example processor platform 1600 of FIG. 16 , which is described in further detail below.
- the compute node 104 of the illustrated example is deployed in an industrial environment, in the other examples, the compute node 104 can be deployed in other types of environments.
- the compute node 104 could correspond to a controller to execute workloads to control fifth generation ( 5 G) small cell sites, cloud center server farms, etc.
- 5 G fifth generation
- the compute node 104 communicates with the physical equipment 114 via an example time sensitive network 116 .
- the time sensitive network 116 connects the compute node 104 with the physical equipment 114 and, in some examples, other example compute node(s) 118 via an example bridge 120 .
- the bridge 120 can be implemented by any network bridge, router, server, device, etc., capable of implementing a TSN schedule (e.g., a TSN schedule in accordance with the IEEE 802.1Qbv Standard).
- Each of the compute node(s) 118 of the illustrated example can be implemented by any appropriate computing device or combination of computing devices, such as a server in an edge cluster, an industrial computer, etc., which may be similar to, or different from, the computing node 104 .
- the compute node 104 include an example network interface card (MC) 122 .
- the compute node(s) 118 include respective NICs 124 .
- the NICs 122 and 124 can be implemented by any network interface circuitry capable of connecting to the time sensitive network 116 .
- the time sensitive network 116 is a wired network, such as an Ethernet network, a digital subscriber line (DSL) network, etc.
- the NICs 122 and 124 can be implemented by appropriate, corresponding wired network interface circuitry.
- the NICs 122 and 124 can be implemented by appropriate, corresponding wireless network interface circuitry.
- the softswitch 106 implemented on the compute node 104 communicates with the NIC 122 of the compute node 104 via an example data plane development kit (DPDK) 126 .
- the DPDK provides a set of libraries to enable efficient communication of data packets between the softswitch 106 and the NIC 122 .
- the softswitch 106 of the compute node 104 corresponds to a virtual switch implemented by one or more virtual network functions (VNFs) to provide the workloads 108 , 110 , 112 executing on the compute node 104 with access to the time sensitive network 116 , which connects the workloads 108 , 110 , 112 to the physical equipment 114 .
- VNFs virtual network functions
- the softswitch 106 also implements an example internal network 127 to allow some or all of the workloads 108 , 110 , 112 to communicate with each other within the compute node 104 .
- the workloads 108 , 110 , 112 can correspond to any appropriate workload to control the physical equipment 114 , monitor the physical equipment 114 , process data returned by the physical equipment 114 for use in other applications, etc.
- the workloads 108 and 110 correspond to respective example virtual PLCs 108 and 110 executed to control respective physical equipment 114 (e.g., such as respective robots, tools, etc.) in a deterministic and real-time manner.
- the workload 112 of the illustrated example corresponds to a vision processing workload 112 , which is a non-deterministic workload to perform computer vision processing on data returned from one or more of the physical equipment 114 .
- the softswitch 106 can support deterministic and non-deterministic workloads. In the illustrated example of FIG.
- the workloads 108 , 110 , 112 are hosted by respective virtual machines (VMs) and/or containers that interface with the softswitch 106 .
- VMs virtual machines
- the workloads 108 and 110 are hosted by respective example VMs 128 and 130
- the workload 112 is hosted by an example container 132 .
- the VMs 128 and 130 also include respective example virtual NICs (VNICs) 134 and 136 to connect the VMs 128 and 130 with the softswitch 106 .
- VNICs virtual NICs
- the softswitch 106 of the illustrated example implements a TSN schedule, such as a TSN schedule compliant with the IEEE 802.1Qbv Standard, to transmit and receive data packets as part of the time sensitive network 116 .
- the softswitch 106 may include multiple data buffers (e.g., queues) assigned to different data classes defined by the TSN schedule, which the softswitch 106 gates on and off to provide access to the time sensitive network 116 to meet timing requirements specified by the TSN schedule.
- the compute node 104 includes the example network node configurator 138 .
- the other compute node(s) 118 also include respective example network node configurator(s) 139 .
- the network node configurator 138 is also responsible for changing the TSN schedule implemented by the softswitch 106 when an updated TSN schedule is deployed to the compute node 104 .
- the network node configurator 138 is also responsible for validating the updated TSN schedule before deploying the updated TSN schedule for softswitch implementation. For example, an updated TSN schedule may be deployed to the compute node 104 when a new workload, such as an example workload 140 , is to be deployed to the compute node 104 for execution. As shown in FIG.
- the workload 140 may be similar to, or different from, the workloads 108 , 110 , 112 , and may be hosted by an example VM 142 with an example VNIC 144 .
- the updated TSN schedule is created to accommodate the packet communication timing requirements of the new workload 140 to be deployed on the compute node 104 , as well as the packet communication timing requirements of existing workloads operating in the time sensitive network 116 , such as the workloads 108 , 110 and 112 .
- the network node configurator 138 utilizes one or more example data repositories 146 to configure the softswitch 106 to implement a TSN schedule, to change the TSN schedule implemented by the softswitch 106 , to confirm that an updated TSN schedule is viable before deploying the updated TSN schedule for softswitch implementation, etc.
- the data repositories 146 can be implemented by any number and/or type(s) of storage devices, memories, etc.
- the data repositories 146 can be implemented by the example volatile memory 1614 and/or the example mass storage device(s) 1628 of FIG. 16 , which are described in further detail below.
- the central configuration controller 102 is included in the example environment 100 to deploy workloads and TSN schedules to the compute nodes 104 and 118 in communication with the time sensitive network 116 .
- the central configuration controller 102 communicates with the compute nodes 104 and 118 via an example network 148 .
- the network 148 can be implemented by any number and/or type(s) of communication networks.
- the communication network 125 can be implemented by one or more wired/cabled networks, one or more wireless networks (e.g., mobile cellular networks, satellite networks, etc.), one or more proprietary networks, one or more public networks (e.g., such as the Internet), etc., or any combination thereof.
- the network 148 is different from the time sensitive network 116 that connects the compute nodes 104 and 118 with the physical equipment 114 .
- the central configuration controller 102 can be implemented by, for example, any appropriate computing device or combination of computing devices.
- the central configuration controller 102 is implemented by a processor platform such as the example processor platform 1500 of FIG. 15 , which is described in further detail below.
- the central configuration controller 102 includes an example orchestrator 150 to deploy workloads to the compute nodes 104 and 118 .
- the central configuration controller 102 of the illustrated example also includes an example central user configurator 152 and an example central network configurator 154 to configure the time sensitive network 116 .
- the central network configurator 154 includes an example scheduler 156 to create TSN schedules to be deployed to the network nodes 104 and 118 to implement the time sensitive network 116 .
- the workloads and TSN schedules are created based on example virtualized industrial function descriptors (VIFD) 158 that specify the instantiation parameters, operational behaviors, network communication requirements, etc., for the workloads to be deployed to the compute nodes 104 and 118 .
- VIP virtualized industrial function descriptors
- An example procedure performed by the central configuration controller 102 and the network node configurator 138 to change a TSN schedule implemented by the softswitch 106 of the compute node 104 is described in further detail below in connection with FIGS. 1-5 .
- An example VIFD 158 is illustrated in FIG. 6 , which is also described in further detail below.
- an example procedure performed by the central configuration controller 102 and the network node configurator 138 to change a TSN schedule implemented by the softswitch 106 of the compute node 104 begins with the central configuration controller 102 receiving the VIFD 158 for the new workload 140 to be deployed to the compute node 104 .
- the VIFD 158 specifies the instantiation parameters, operational behaviors, network communication requirements, etc., for the new workload 140 .
- the VIFD 158 is an enhancement of the virtual network function descriptor (VNFD) specified by the European Telecommunications Standards Institute (ETSI) in the specification “Network Functions Virtualisation (NFV) Release 2; Protocols and Data Models; NFV descriptors based on TOSCA specification,” version 2.5.1, published in December 2018.
- VNFD virtual network function descriptor
- ETSI European Telecommunications Standards Institute
- NFV Network Functions Virtualisation
- TOSCA Topology and Orchestration Specification for Cloud Applications
- a VNFD uses the TOSCA language to specify the instantiation parameters and operational behaviors of VNF workloads.
- the VNFD can contain key performance indicators (KPIs) and/or other requirements that can be used in the process of onboarding and managing the lifecycle of the VNF workloads.
- KPIs key performance indicators
- a VNFD does not describe the real-time networking requirements for a workload, such as packet communication jitter targets/bounds, latency targets/bounds, etc.
- the VIFD 158 extends the VNFD to include network communication scheduling requirements for the workload 140 , such as frame spacing, mean latency, an upper bound for latency, etc.
- the example VIFD 158 of FIG. 6 includes an example topology definition section 605 , which specifies the instantiation parameters and operational behaviors of the workload 140 .
- the example VIFD 158 of FIG. 6 also includes an example scheduling constraints definition section 610 , which specifies the network communication scheduling requirements for the workload 140 .
- the orchestrator 150 and the central user configurator 152 read the VIFD 158 for the workload 140 .
- the orchestrator 150 parses the VM-related fields of the VIFD 158 to define the resource requirements (e.g. number of virtual central processing units (CPUs), memory, storage, network interfaces, etc.) for the workload 140 to be deployed (e.g., in real-time) to the compute node 104 (e.g., which may be an edge compute node or cluster in an industrial computer premises system).
- the resource requirements e.g. number of virtual central processing units (CPUs), memory, storage, network interfaces, etc.
- the orchestrator 150 parses the topology definition section 605 of the VIFD 158 to determine the parameters (e.g., VM flavor, number of network connections, image name, number of cores, core isolation, core pinning, memory/disk sizes, etc.) to be used by the orchestrator to create a VM configuration specification for the VM 142 , which is to host the workload 140 on the compute node 104 .
- the parameters e.g., VM flavor, number of network connections, image name, number of cores, core isolation, core pinning, memory/disk sizes, etc.
- the orchestrator 150 then creates the VM configuration specification for the VM 142 based on the parameters parsed from the VIFD 158 , and sends (e.g., transmits) the VM configuration specification (e.g., via the network 148 ) to the compute node 104 to deploy the VM 142 and workload 140 to the compute node 104 .
- the orchestrator 150 is an example of means for parsing a virtualized industrial function descriptor to determine a virtual machine configuration specification for a virtual machine to deploy on a compute node to implement a virtualized workload.
- the central user configurator 152 parses the scheduling-related fields of the VIFD 158 to determine the network communication scheduling requirements for the workload 140 .
- the central user configurator 152 parses the scheduling constraints definition section 610 of the VIFD 158 to identify the network communication scheduling parameters specified for the workload 140 , which will be used by the central network configurator 154 to create an updated TSN schedule to accommodate the workload 140 in the time sensitive network 116 .
- the central user configurator 152 is implemented to meet the functional requirements of a central user configurator in accordance with the IEEE 802.1Qcc Standard, published on Oct. 31, 2018.
- the central user configurator 152 is an architectural component of a TSN environment, and is responsible for the discovery of end stations, retrieving end station capabilities and user requirements, etc. In the illustrated example of FIG. 1 , the central user configurator 152 is responsible for identifying the network communication scheduling parameters specified in the VIFD 158 for the workload 140 , and for transposing the identified network communication scheduling parameters into a parameter set supported by the central network configurator 154 . In some examples, the central user configurator 152 determines whether the network communication scheduling parameters identified in the VIFD 158 for the workload 140 are supported by the central network configurator 154 .
- the central user configurator 152 replaces the unsupported parameter with a different parameter (e.g., a nearest approximation) supported by the central network configurator 154 .
- the central user configurator 152 discards the unsupported parameter (e.g., if a suitable substitute is not available).
- the central user configurator 152 is an example of means for parsing a virtualized industrial function descriptor corresponding to a virtualized workload to determine a set of parameters for an updated time sensitive networking schedule to be implemented by one or more softswitches.
- the central user configurator 152 may provide an updated time sensitive networking schedule to one softswitch to address communication requirements among workloads on the compute node associated with that softswitch.
- the central user configurator 152 may provide an updated time sensitive networking schedule to multiple softswitches to address communication requirements across the time sensitive network 116 among workloads on different compute nodes associated with the different softswitches.
- the central network configurator 154 provides a centralized means for performing resource reservation, scheduling, configuration of the compute nodes 104 , 118 and the time sensitive network 116 , etc.
- the central network configurator 154 communicates with the compute nodes 104 , 118 , and possibly other elements of the time sensitive network 116 (e.g., the bridge 120 , etc.), via a remote management protocol, such as the network configuration protocol (NETCONF), RESTCONF, etc.
- NETCONF network configuration protocol
- RESTCONF RESTCONF
- the central network configurator 154 includes the scheduler 156 to create an updated TSN schedule based on the set of scheduling parameters provided by the central user configurator 152 (e.g., after any replacing/discarding, as described above) to accommodate the new workload 140 .
- the scheduler 156 of the central network configurator 154 creates the updated TSN schedule that complies with IEEE 802.1Qbv Standard and is intended to meet the real-time, isochronous packet transmission requirements specified in the VIFD 158 for the workload 140 .
- the central network configurator 154 is an example of means for determine an updated TSN schedule based on a set of parameters specified for a virtualized workload.
- the updated TSN schedule when it is ready, it is sent to the network node configurator 138 of the compute node 104 for deployment to the softswitch 106 .
- the updated TSN schedule may be sent via an end station configuration protocol, which may be based on a publish/subscribe mechanism, such as the OPC unified architecture (OPC-UA) protocol.
- OPC-UA OPC unified architecture
- the network node configurator 138 in response to receiving the updated TSN schedule, creates (e.g., instantiates) an example duplicate softswitch 205 , which is a duplicate or digital twin of the existing softswitch 205 .
- the network node configurator 138 uses the duplicate softswitch 205 to test the updated TSN schedule and, upon successful validation, to apply the new TSN schedule at the compute node 104 without interruption of the existing workload 108 , 110 , 112 connected to the softswitch 106 .
- the network node configurator 138 is an example of means for replacing a first softswitch implementing a first (e.g., existing) TSN schedule at a compute node with a second softswitch to implement a second (e.g., updated) TSN schedule at the compute node, which can include deploying the second softswitch on the compute node with an initial configuration based on (e.g., matching) the configuration of the first softswitch, configuring the second softswitch to implement the second (e.g., updated) TSN schedule, and replacing the first softswitch with the second softswitch after validation of the second TSN schedule implemented by the second softswitch.
- a first softswitch implementing a first (e.g., existing) TSN schedule at a compute node with a second softswitch to implement a second (e.g., updated) TSN schedule at the compute node
- the network node configurator 138 accesses a configuration specification for the softswitch 106 from a softswitch specification repository included in the repositories 146 and/or downloaded from the central configuration controller 102 .
- the configuration specification for the softswitch 106 may specify the configuration(s) of the VNF(s) and VM(s) implementing the softswitch 106 , and/or any other configuration settings/data that define the implementation of the softswitch 106 .
- the network node configurator 138 also accesses any real-time metrics, status, etc., from the softswitch 106 .
- the network node configurator 138 uses the accessed configuration specification for the softswitch 106 , and any other metrics, status, etc., to create/instantiate the duplicate softswitch 205 on the compute node 104 such that the duplicate softswitch 205 is a digital copy (or digital twin) of the softswitch 106 .
- the network node configurator 138 uses the configuration specification for the softswitch 106 to create/instantiate the duplicate softswitch 205 on the compute node 104 such that the duplicate softswitch 205 is an exact duplicate (e.g., a digital twin) of the softswitch 106 .
- the network node configurator 138 uses the configuration specification for the softswitch 106 to create/instantiate the duplicate softswitch 205 on the compute node 104 such that the duplicate softswitch 205 is substantially similar to the softswitch 106 , except for some inconsequential differences in the configuration parameters.
- the configuration specification for the softswitch 106 may specify configuration parameters defining the composition of the softswitch 106 , such as a number of processing cores, an amount of memory, total number of data buffers (e.g., queues) for transmitting and receiving data packets, distribution of the data buffers (e.g., queues) across different data traffic classes (e.g., in terms of the number of data buffers assigned to each different data class), number of port connections assignable to VMs, etc.
- configuration parameters defining the composition of the softswitch 106 such as a number of processing cores, an amount of memory, total number of data buffers (e.g., queues) for transmitting and receiving data packets, distribution of the data buffers (e.g., queues) across different data traffic classes (e.g., in terms of the number of data buffers assigned to each different data class), number of port connections assignable to VMs, etc.
- the network node configurator 138 may create/instantiate the duplicate softswitch 205 such that its configuration specification includes all of the same configuration parameters as the configuration specification of the softswitch 106 .
- the network node configurator 138 may create/instantiate the duplicate softswitch 205 such that its configuration specification includes some of the same configuration parameters as the configuration specification of the softswitch 106 (e.g., such as the same number of processing cores, the same total number of data buffers (e.g., queues) for transmitting and receiving data packets, the same distribution of the data buffers (e.g., queues) across different data traffic classes, etc.), but other configuration parameters may differ (e.g., amount of memory, number of port connections assignable to VMs, etc.) if the parameters that differ will result in little to no change in operational performance between the softswitch 106 and the initially deployed duplicate softswitch 205 .
- the configuration specification includes some of the same configuration parameters as the configuration specification of the softswitch 106 (e.g., such as the same number of processing cores, the same total number of data buffers (e.g., queues) for transmitting and receiving data packets, the same distribution of the data
- the network node configurator 138 also connects the VNIC 144 of the VM 142 , which has been deployed to the compute node 104 to implement the virtualized workload 140 , to the duplicate softswitch 205 .
- the network node configurator 138 may access a VM configuration file for the VM 142 from a VM configuration repository included in the repositories 146 , access a configuration specification for the duplicate softswitch 205 (which initially corresponds/matches the configuration specification for softswitch 106 ) from the softswitch specification repository included in the repositories 146 , and update the configuration files to map a port of VNIC 144 of the VM 142 to a port of the softswitch 205 .
- the network node configurator 138 also configures the workload 140 hosted by the VM 142 to operate in a test mode (e.g., by setting an appropriate configuration setting, value, field, etc.).
- the network node configurator 138 deploys the updated TSN schedule to the softswitch 205 and tests the updated TSN schedule using simulated network traffic.
- the network node configurator 138 includes an example traffic simulator 305 , which implements an on-node simulation engine on the compute node 104 that generates simulated network traffic to validate the updated TSN schedule implemented by the duplicate softswitch 205 before the validated updated TSN schedule is deployed for operation.
- the traffic simulator 305 is illustrated as being implemented by the network node configurator 138 in the illustrated example, in other examples, the traffic simulator 305 could be a separate element implemented on the compute node 104 . Accordingly, the traffic simulator 305 is an example means for applying simulated network traffic to a softswitch.
- the traffic simulator 305 generates the simulated network traffic from actual network traffic monitored by the traffic simulator 305 during operation of the softswitch 106 .
- the traffic simulator 305 can monitor the actual network traffic communicated to/from the elements connected to the softswitch 106 , such as the VMs 128 / 130 and the container 132 , during operation of the workloads 108 , 110 , 112 .
- the traffic simulator 305 stores the monitored network traffic in a simulated network traffic repository included in the repositories 146 .
- the traffic simulator 305 can store the monitored network traffic as one or more packet-capture (PCAP) files in the simulated network traffic repository included in the repositories 146 .
- PCAP packet-capture
- the traffic simulator 305 also obtains a test traffic file, such as a test traffic PCAP file, associated with new workload 140 being deployed to the compute node 104 .
- a test traffic file such as a test traffic PCAP file
- the orchestrator 150 may transmit a test traffic file to the compute node 104 (e.g., to the network node configurator 138 and/or the traffic simulator 305 ) with the VM configuration specification for the VM 142 implementing the new workload 140 , which is stored in the simulated network traffic repository included in the repositories 146 .
- the test traffic file in such examples may be generated to mimic the network traffic to be transmitted to and/or received from the type of physical equipment expected to be in communication with the workload 140 .
- the simulated network traffic repository included in the repositories 146 may store a library of different test traffic files for different types of workloads, and the traffic simulator 305 may select a network traffic file for the workload 140 from the repository based on the type of the workload 140 .
- the traffic simulator 305 generates the simulated network traffic to validate the updated TSN schedule by combining the previously monitored network traffic, which is associated with prior operation of the softswitch 106 , with the test traffic file associated with the new workload 140 .
- the traffic simulator 305 then applies the simulated network traffic to the duplicate softswitch 205 by simulating appropriate virtual sources and sinks to send and receive the simulated network traffic processed by the duplicate softswitch 205 .
- the traffic simulator 305 also implements a virtual sink to receive network traffic sent by the workload 140 (and VM 142 ), which is operating in test mode, to process simulated network traffic received by the VM 142 and workload 140 (e.g., based on the test traffic file).
- the network node configurator 138 then monitors traffic performance metrics associated with the simulated network traffic processed by the duplicate softswitch 205 based on the updated TSN schedule.
- one or more virtual network sinks implemented by the traffic simulator 305 may be configured to receive the simulated network traffic traversing the duplicate softswitch 205 and generate traffic performance metrics (e.g., such as packet jitter, packet latency, etc.) from the simulated network traffic before discarding the simulated network packets.
- the virtual sinks(s) may generate the traffic performance metrics for the simulated network traffic associated with (e.g., receive and/or transmitted) by the workload 140 (also referred to as the simulated traffic performance metrics for the workload 140 ).
- the virtual sinks(s) may generate the traffic performance metrics for the respective simulated network traffic associated with (e.g., previously monitored for) one, or more, or all of the other workloads 108 , 110 , 112 (also referred to as the simulated traffic performance metrics for the workloads 108 , 110 , 112 ).
- the network node configurator 138 and/or traffic simulator 305 monitor switch metrics associated with operation of the duplicate softswitch 205 to process the simulated network traffic (e.g., such as buffer/queue utilization and/or overflow for different traffic classes specified by the updated TSN schedule, detected violations of the gate structure specified by the updated TSN schedule, etc.).
- the application of simulated network traffic to the duplicate softswitch 205 , and the corresponding monitoring of the performance metrics, is represented by the directed line 310 in the example of FIG. 3 .
- the network node configurator 138 monitors the traffic performance metrics and switch metrics, if available, associated with the simulated network traffic processed on the duplicate softswitch 205 based on the updated TSN schedule and compares the monitored performance metrics to one or more sets of constraints to validate the updated TSN schedule.
- the constraints may correspond to one or more of the network communication scheduling requirements specified in the VIFD 158 for the new workload 140 being deployed to the compute node 104 .
- the central user configurator 152 and/or the central network configurator 154 provide (e.g., with the deployment of the updated TSN schedule to the compute node 104 ) one or more sets of network performance constraints for the new workload 140 , which are parsed from the VIFD 158 , to the network node configurator 138 .
- the network node configurator 138 can then store the one or more sets of network performance constraints for the workload 140 in a workload scheduling and metrics specification repository included in the repositories 146 .
- the workload scheduling and metrics specification repository included in the repositories 146 may contain stored sets of network performance constraints previously received from the central user configurator 152 and/or the central network configurator 154 for the other workloads 108 , 110 and 112 . Examples of such network performance constraints include a frame spacing target, mean packet latency target, and upper packet latency bound, etc.
- the workload scheduling and metrics specification repository included in the repositories 146 may also include targets for the switch metrics monitored by the network node configurator 138 .
- the network performance constraints obtained for the workload 140 are identified to indicate the importance, or severity, of the constraint.
- a constraint may be identified as a first type of constraint corresponding to a hard constraint that must be met by the monitored traffic metrics in order for the associated workload for the updated TSN schedule to be considered valid, or as a second type of constraint corresponding to a soft constraint that is desired to be met but not required in order for the updated TSN schedule to be considered valid.
- the network node configurator 138 groups the network performance constraints to be evaluated into a first set of constraints including the identified first type of constraints (e.g., hard constraints) and a second set of constraints including the identified second type of constraints (e.g., soft constraints).
- the network node configurator 138 may spend an amount of time up to a bounded time limit to adjust the configuration of the duplicate softswitch 205 to meet one or more of the constraints included in the second set of constraints (e.g., the soft constraints).
- the bounded time limit also referred to as an optimization time limit
- the VIFD 158 is specified in the VIFD 158 for the new workload 140 being deployed to the compute node 104 , and is provided to the network node configurator 138 by the central user configurator 152 and/or the central network configurator 154 with the other constraints.
- the optimization time limit may be related to an amount of delay that can be tolerated while the workload 140 is being deployed to the compute node 104 .
- the network node configurator 138 compares the simulated traffic performance metrics for workload 140 and, in some examples, the simulated traffic performance metrics for the other workloads 108 , 110 , 112 processed by the duplicate softswitch 205 , with the respective sets of constraints for the corresponding workloads to determine whether the updated TSN schedule implemented by the duplicate softswitch 205 is valid. In some examples, the network node configurator 138 may also compare the switch metrics determined for the duplicate softswitch 205 when processing the simulated network traffic to corresponding targets to determine whether the updated TSN schedule implemented by the duplicate softswitch 205 is valid.
- the network node configurator 138 determines the updated TSN schedule is valid if the simulated traffic performance metrics associated with the workload 140 satisfy the first set of constraints.
- the network node configurator 138 determines the updated TSN schedule is valid if the simulated traffic performance metrics associated with the respective workloads 108 , 110 , 112 also satisfy their corresponding first sets of constraints.
- the first sets of constraints corresponding to hard constraints may be constraints that, if met, indicate that deterministic packet scheduling has been achieved with the updated TSN schedule and that threshold network performance targets for the corresponding workloads are met.
- the network node configurator 138 determines whether the second set of constraints corresponding to soft constraints for the workload 140 . In some examples, the network node configurator 138 also determines whether the respective second sets of constraints corresponding to soft constraints for the workloads 108 , 110 , 112 have also been met. If one or more of the soft constraints in the second set of constraints have not been met, the network node configurator 138 adjusts the configuration of the duplicate softswitch 205 to enable one or more of the soft constraints to be met.
- the duplicate softswitch 205 may include multiple data buffers (e.g., queues) assigned to different data classes defined by the TSN schedule, which the duplicate softswitch 205 gates on and off to allow traffic to packets in the buffers to traverse the softswitch 205 to meet timing requirements specified by the updated TSN schedule.
- data buffers e.g., queues
- the network node configurator 138 may adjust the number of data buffers (e.g., queues) assigned to the different data classes defined by the TSN schedule, adjust when and/or how often and/or for how long different ones of the data buffers (e.g., queues) are gated on to allow their respective packets to traverse the softswitch 205 , etc.
- the network node configurator 138 adjusts the duplicate softswitch 205 iteratively such that ones of the soft constraints are met in priority weighting order, with higher soft constraints being optimized before lower soft constraints, resulting in iterative optimization of the soft constraints.
- the network node configurator 138 continues adjusting the configuration of the duplicate softswitch 205 iteratively until all soft constraints are met or until the bounded time limit for adjusting the configuration of the duplicate softswitch 205 is reached. At this point, the updated TSN schedule and configuration of the duplicate softswitch 205 are finalized and ready to be deployed on the compute node 104
- the network node configurator 138 determines the updated TSN schedule is not valid (e.g., because one or more of the first set of constraints corresponding to hard constraints, such as a frame delivery deadline, are not met by the updated TSN schedule)
- the network node configurator 138 generates a failure message and sends the failure message to the central configuration controller 102 for receipt by the central user configurator 152 and the orchestrator 150 .
- the orchestrator 150 causes the new virtualized workload 140 instance to be deleted from the compute node 104 (e.g., by deleting its VM 142 ).
- the network node configurator 138 also deletes the updated TSN schedule and the duplicate softswitch 205 from the compute node 104 .
- the network node configurator 138 determines the updated TSN schedule is valid (e.g., because the first set of constraints corresponding to hard constraints, such as a frame delivery deadline, are met by the updated TSN schedule)
- the network node configurator 138 generates a success message and sends the success message to the central configuration controller 102 for receipt by the central user configurator 152 and the orchestrator 150 .
- the network node configurator 138 is also responsible for replacing the existing softswitch 106 with the new softswitch 205 and transitioning the new workload 140 and the existing workloads 108 , 110 and 112 to the new softswitch 205 .
- the network node configurator 138 connects the newly configured softswitch 205 implementing the updated TSN schedule to the NIC 122 of the compute node via the DPDK 126 (e.g., by updating the configuration specifications of the respective softswitches 106 and 205 ).
- the network node configurator 138 also adds new port connections to the respective VMs/containers 128 , 130 , 132 implementing the corresponding existing workloads 108 , 110 , 112 , binds the new ports to the new softswitch 205 , and deletes the previous port bindings associated with the softswitch 106 , as shown (e.g., by updating the configuration files for the VMs/containers 128 , 130 , 132 and the softswitches 106 and 205 ).
- the network node configurator 138 also configures the new workload 140 hosted by the VM 142 to operate in an operational mode instead of test mode (e.g., by setting an appropriate configuration setting, value, field, etc.).
- the network node configurator 138 also stores the configuration specification for the new softswitch 205 in the softswitch specification repository included in the repositories 146 and/or reports the configuration specification for the new softswitch 205 to the central configuration controller 102 .
- the network node configurator 138 deletes the old softswitch 106 from the compute node 104 and deletes its configuration specification from the softswitch specification repository included in the repositories 146 . In this manner, the network node configurator 138 replaces the old softswitch 106 implementing the old TSN schedule with the new softswitch 205 implementing the updated TSN schedule.
- the switchover is performed after the updated TSN schedule implemented by the new softswitch 205 is verified with the simulated network traffic, and can be accomplished quickly by updating configuration specification files for the VMs/containers 128 , 130 , 132 and softswitches 106 , 205 , the existing workloads 108 , 110 and 112 can experience negligible downtime during the switchover.
- the traffic simulator 305 monitors the network traffic traversing the new softswitch 205 (e.g., which is associated with the workloads 108 , 110 , 112 and 140 ) and stores the monitored network traffic (e.g., as one or more PCAP files) in the simulated network traffic repository included in the repositories 146 .
- This monitored network traffic stored in the simulated network traffic repository included in the repositories 146 can later be used, as described above, when another updated TSN schedule is to be deployed to the compute node 104 .
- FIG. 7 A block diagram of an example implementation of the network node configurator 138 of FIGS. 1-5 is illustrated in FIG. 7 .
- the example network node configurator 138 of FIG. 7 includes an example softswitch instantiator 705 to instantiate the duplicate softswitch 205 on the compute node 104 in response to receiving the updated TSN schedule, as described above.
- the network node configurator 138 of FIG. 7 includes an example TSN schedule configure 710 to configure the duplicate softswitch 205 to implement the updated TSN schedule, as described above.
- the network node configurator 138 of FIG. 7 includes the example traffic simulator 305 and an example TSN schedule validator 715 to validate the updated TSN schedule implemented by the duplicate softswitch 205 , as described above.
- the network node configurator 138 of FIG. 7 includes an example softswitch replacer 720 to replace the existing softswitch 106 with the new softswitch 205 on the compute node 104 in response to successful validation of the updated TSN schedule, as described above.
- FIGS. 1-7 While example manners of implementing the example central configuration controller 102 and the example network node configurator 138 are illustrated in FIGS. 1-7 , one or more of the elements, processes and/or devices illustrated in FIGS. 1-7 may be combined, divided, re-arranged, omitted, eliminated and/or implemented in any other way.
- the example orchestrator 150 may be implemented by hardware, software, firmware and/or any combination of hardware, software and/or firmware.
- any of the example orchestrator 150 , the example central user configurator 152 , the example central network configurator 154 , the example scheduler 156 , the example traffic simulator 305 , the example softswitch instantiator 705 , the example TSN schedule configure 710 , the example TSN schedule validator 715 , the example softswitch replacer 720 and/or, more generally, the example central configuration controller 102 and the example network node configurator 138 could be implemented by one or more analog or digital circuit(s), logic circuits, programmable processor(s), programmable controller(s), graphics processing unit(s) (GPU(s)), digital signal processor(s) (DSP(s)), application specific integrated circuit(s) (ASIC(s)), programmable logic device(s) (PLD(s)), field programmable gate arrays (FPGAs) and/or field programmable logic device(s) (FPLD(s)).
- analog or digital circuit(s) logic circuits
- At least one of the example central configuration controller 102 , the example network node configurator 138 , the example orchestrator 150 , the example central user configurator 152 , the example central network configurator 154 , the example scheduler 156 , the example traffic simulator 305 , the example softswitch instantiator 705 , the example TSN schedule configure 710 , the example TSN schedule validator 715 and/or the example softswitch replacer 720 is/are hereby expressly defined to include a non-transitory computer readable storage device or storage disk such as a memory, a digital versatile disk (DVD), a compact disk (CD), a Blu-ray disk, etc.
- DVD digital versatile disk
- CD compact disk
- Blu-ray disk etc.
- the example central configuration controller 102 and/or the example network node configurator 138 of FIGS. 1-7 may include one or more elements, processes and/or devices in addition to, or instead of, those illustrated in FIGS. 1-7 , and/or may include more than one of any or all of the illustrated elements, processes and devices.
- the phrase “in communication,” including variations thereof, encompasses direct communication and/or indirect communication through one or more intermediary components, and does not require direct physical (e.g., wired) communication and/or constant communication, but rather additionally includes selective communication at periodic intervals, scheduled intervals, aperiodic intervals, and/or one-time events.
- FIGS. 8-14 Flowcharts and pseudocode representative of example hardware logic, machine readable instructions, hardware implemented state machines, and/or any combination thereof for implementing the example central configuration controller 102 and the example network node configurator 138 are shown in FIGS. 8-14 .
- the machine readable instructions may be one or more executable programs or portion(s) of an executable program for execution by a computer processor, such as the processor 1512 and/or 1612 shown in the example processor platforms 1500 and 1600 discussed below in connection with FIGS. 15-16 .
- the one or more programs, or portion(s) thereof may be embodied in software stored on a non-transitory computer readable storage medium such as a CD-ROM, a floppy disk, a hard drive, a DVD, a Blu-ray DiskTM, or a memory associated with the processors 1512 and/or 1612 , but the entire program or programs and/or parts thereof could alternatively be executed by a device other than the processors 1512 and/or 1612 , and/or embodied in firmware or dedicated hardware. Further, although the example program(s) is(are) described with reference to the flowcharts and pseudocode illustrated in FIGS.
- any or all of the blocks may be implemented by one or more hardware circuits (e.g., discrete and/or integrated analog and/or digital circuitry, an FPGA, an ASIC, a comparator, an operational-amplifier (op-amp), a logic circuit, etc.) structured to perform the corresponding operation without executing software or firmware.
- hardware circuits e.g., discrete and/or integrated analog and/or digital circuitry, an FPGA, an ASIC, a comparator, an operational-amplifier (op-amp), a logic circuit, etc.
- the machine readable instructions described herein may be stored in one or more of a compressed format, an encrypted format, a fragmented format, a compiled format, an executable format, a packaged format, etc.
- Machine readable instructions as described herein may be stored as data (e.g., portions of instructions, code, representations of code, etc.) that may be utilized to create, manufacture, and/or produce machine executable instructions.
- the machine readable instructions may be fragmented and stored on one or more storage devices and/or computing devices (e.g., servers).
- the machine readable instructions may require one or more of installation, modification, adaptation, updating, combining, supplementing, configuring, decryption, decompression, unpacking, distribution, reassignment, compilation, etc.
- the machine readable instructions may be stored in multiple parts, which are individually compressed, encrypted, and stored on separate computing devices, wherein the parts when decrypted, decompressed, and combined form a set of executable instructions that implement a program such as that described herein.
- the machine readable instructions may be stored in a state in which they may be read by a computer, but require addition of a library (e.g., a dynamic link library (DLL)), a software development kit (SDK), an application programming interface (API), etc. in order to execute the instructions on a particular computing device or other device.
- a library e.g., a dynamic link library (DLL)
- SDK software development kit
- API application programming interface
- the machine readable instructions may need to be configured (e.g., settings stored, data input, network addresses recorded, etc.) before the machine readable instructions and/or the corresponding program(s) can be executed in whole or in part.
- the disclosed machine readable instructions and/or corresponding program(s) are intended to encompass such machine readable instructions and/or program(s) regardless of the particular format or state of the machine readable instructions and/or program(s) when stored or otherwise at rest or in transit.
- the machine readable instructions described herein can be represented by any past, present, or future instruction language, scripting language, programming language, etc.
- the machine readable instructions may be represented using any of the following languages: C, C++, Java, C #, Perl, Python, JavaScript, HyperText Markup Language (HTML), Structured Query Language (SQL), Swift, etc.
- FIGS. 8-14 may be implemented using executable instructions (e.g., computer and/or machine readable instructions) stored on a non-transitory computer and/or machine readable medium such as a hard disk drive, a flash memory, a read-only memory, a compact disk, a digital versatile disk, a cache, a random-access memory and/or any other storage device or storage disk in which information is stored for any duration (e.g., for extended time periods, permanently, for brief instances, for temporarily buffering, and/or for caching of the information).
- a non-transitory computer readable medium is expressly defined to include any type of computer readable storage device and/or storage disk and to exclude propagating signals and to exclude transmission media.
- the terms “computer readable” and “machine readable” are considered equivalent unless indicated otherwise.
- A, B, and/or C refers to any combination or subset of A, B, C such as (1) A alone, (2) B alone, (3) C alone, (4) A with B, (5) A with C, (6) B with C, and (7) A with B and with C.
- the phrase “at least one of A and B” is intended to refer to implementations including any of (1) at least one A, (2) at least one B, and (3) at least one A and at least one B.
- the phrase “at least one of A or B” is intended to refer to implementations including any of (1) at least one A, (2) at least one B, and (3) at least one A and at least one B.
- the phrase “at least one of A and B” is intended to refer to implementations including any of (1) at least one A, (2) at least one B, and (3) at least one A and at least one B.
- the phrase “at least one of A or B” is intended to refer to implementations including any of (1) at least one A, (2) at least one B, and (3) at least one A and at least one B.
- An example program 800 that may be executed to implement the example central configuration controller 102 of FIG. 1 is represented by the flowchart shown in FIG. 8 .
- the example program 800 begins execution at block 805 at which the central configuration controller 102 accesses the VIFD 158 specifying the new workload 140 to deploy to the compute node 104 .
- the orchestrator 150 of the central configuration controller 102 parses the VIFD 158 to determine a VM configuration specification to implement the workload 140 , as described above.
- the central user configurator 152 of the central configuration controller 102 parses the VIFD to determine a set of parameters for an updated TSN schedule to accommodate the workload 140 , as described above.
- the central network configurator 154 of the central configuration controller 102 determines, as described above, the updated TSN schedule based on the set of parameters parsed from the VIFD 158 at block 815 .
- the orchestrator 150 sends the VM configuration specification and a corresponding test traffic file to the compute node 104 to deploy the workload 140 at the compute node 104 , as described above.
- the central network configurator 154 sends the updated TSN schedule to the compute node for deployment at the compute node 104 , as described above.
- the central configuration controller 102 later receives a message, as described above, which indicates a deployment result for deploying the workload 140 and the updated TSN schedule at the compute node 104 . If, at block 840 , the central configuration controller 102 determines the message indicates the updated TSN schedule was not deployable (e.g., was found to be invalid), processing proceeds to block 845 ; otherwise processing proceeds to block 850 .
- the orchestrator 150 deletes the VM configuration specification for the workload 140 and the central network configurator 154 deletes the updated TSN schedule, as described above, which cancels the attempt to deploy the workload 140 and the updated TSN schedule to the compute node 104 .
- the orchestrator 150 retains the VM configuration specification for the workload 140 and the central network configurator 154 retains the updated TSN schedule, as described above, which tracks the successful deployment of the workload 140 and the updated TSN schedule to the compute node 104 .
- An example program 900 that may be executed to implement the example network node configurator 138 of FIGS. 1-5 and/or 7 is represented by the flowchart shown in FIG. 9 .
- the example program 900 begins execution at block 905 at which the network node configurator 138 accesses a VM configuration specification and associated test traffic file received from the central configuration controller 102 for the new workload 140 to be deployed at the compute node 104 , as described above.
- the network node configurator 138 accesses an updated TSN schedule received from the central configuration controller 102 for implementation by the softswitch 106 on the compute node 104 , as described above.
- the softswitch instantiator 705 of the network node configurator 138 deploys the duplicate softswitch 205 on the compute node 104 based on (e.g., to match) a first configuration of the softswitch 106 executing on the compute node 104 , as described above.
- the TSN schedule configure 710 of the network node configurator 138 configures the duplicate softswitch 205 to implement the updated TSN schedule, as described above.
- the TSN schedule validator 715 of the network node configurator 138 determines whether a first set of constraints (e.g., hard constraints) is met for simulated network traffic processed by the duplicate softswitch 205 based on the updated TSN schedule, as described above.
- a first set of constraints e.g., hard constraints
- An example program 925 P that may be executed to implement the processing at block 925 is illustrated in FIG. 10 , which is described below.
- processing proceeds to block 935 ; otherwise processing proceeds to block 940 .
- the network node configurator 138 determines the updated TSN schedule is invalid and, thus, deletes the duplicate softswitch 205 and the VM 142 that was deployed to implement the workload 140 , as described above.
- the network node configurator 138 reports a deployment failure status message to the central configuration controller 102 , as described above.
- the network node configurator 138 determines the updated TSN schedule is valid and, thus, adjusts the second configuration associated with the duplicate softswitch 205 to satisfy one or more of a second set of constraints (e.g., soft constraints) to be met for the simulated network traffic processed by the duplicate softswitch 205 based on the updated TSN schedule, as described above.
- the softswitch replacer 720 of the network node configurator 138 replaces the existing softswitch 106 with the new softswitch 205 , as describe above.
- An example program 950 P that may be executed to implement the processing at block 950 is illustrated in FIG. 12 , which is described below.
- the network node configurator 138 reports a deployment success status message to the central configuration controller 102 , as described above.
- FIG. 10 An example program 925 P that may be executed to implement the processing at block 925 of FIG. 9 is illustrated in FIG. 10 .
- the example program 925 P begins execution at block 1005 at which the example TSN schedule validator 715 of the network node configurator 138 connects a port of the VM 142 , which is being deployed to implement the workload 140 , to the duplicate softswitch 205 , as described above.
- the TSN schedule validator 715 configures the workload 140 hosted by the VM 142 to operate in test mode, as described above.
- the TSN schedule validator 715 invokes the traffic simulator 305 to apply simulated network traffic to the duplicate softswitch 205 , as described above.
- the TSN schedule validator 715 monitors metrics associated with the simulate network traffic processed by the softswitch 205 based on the updated TSN schedule, as described above.
- the TSN schedule validator 715 compares the monitored metrics to the first set of constraints (e.g., hard constraints), as described above.
- Example pseudocode 1025 S that may be executed to implement the processing at block 1025 is illustrated in FIG. 11 .
- FIG. 12 An example program 950 P that may be executed to implement the processing at block 950 of FIG. 9 is illustrated in FIG. 12 .
- the example program 950 P begins execution at block 1205 at which the softswitch replacer 720 of the network node configurator 138 connects the new softswitch 205 to the NIC 122 of the compute node 104 , as described above.
- the softswitch replacer 720 adds respective new port connections to the corresponding existing VMs/containers 128 , 130 , 132 implemented the existing workloads 108 , 110 , 112 on the compute node 104 , as described above.
- the softswitch replacer 720 binds the new port connections of the VMs/containers 128 , 130 , 132 to the new softswitch 205 , as described above.
- the softswitch replacer 720 deletes the prior port connections of the VMs/containers 128 , 130 , 132 that connected to the softswitch 106 , as described above.
- the softswitch replacer 720 sets the new workload 140 hosted by the new VM 142 , which is already connected to the new softswitch 205 , to operational mode, as described above.
- the softswitch replacer 720 deletes the softswitch 106 from the compute node 104 , as described above.
- the softswitch replacer 720 invokes the traffic simulator 305 to monitor the network traffic processed by the new softswitch 205 based on the updated TSN schedule to generate new simulated network traffic to be used to validate future TSN schedule updates, as described above.
- An example program 1300 that may be executed to implement the example central configuration controller 102 and the example network node configurator 138 is represented by the flowchart shown in FIGS. 13-14 .
- the example program 1300 begins execution at block 1302 at which the central user configurator 152 of the central configuration controller 102 accesses and parses the VIFD 158 for the workload 140 corresponding to a new service deployment to obtain the network scheduling requirements for the workload 140 , as described above.
- the central network configurator 154 determines an updated TSN schedule based on the network scheduling requirements parsed from the VIFD 158 , as described.
- the network node configurator 138 receives from the central network configurator 154 the updated TSN schedule and set(s) of constraints to be evaluated to validate the updated TSN schedule on the compute node 104 , as described above.
- the orchestrator 150 of the central configuration controller 102 parses the VIFD 158 for the workload 140 to determine the workload deployment requirements to be used to create the VM 142 (or container) to be deployed to implement the new workload 140 , as described above. Processing then proceeds to an example subroutine 1310 , which is illustrated in FIG. 14 .
- the subroutine 1310 of FIG. 14 begins execution at block 1312 at which the orchestrator 150 deploys the VM 142 on the compute node 104 to implement the workload 140 at the compute node 104 .
- the orchestrator 150 sends a test traffic file for the workload 140 to the network node configurator 138 , as described above.
- the network node configurator 138 receives, from the central network configurator 154 , the updated TSN schedule and the set(s) of constraints parsed from VIFD 158 , and initiates deployment of the duplicate softswitch 206 , as described above.
- the central network configurator 154 deploys, as described above, the duplicate softswitch 206 based on (e.g., to match) the configuration specification obtained for the existing softswitch 106 from the softswitch specification repository included in the repositories 146 (represented by block 1320 in FIG. 14 ).
- the network node configurator 138 connects the VM 142 implementing the new workload 140 to the duplicate softswitch 205 and sets the workload 140 hosted by the VM 142 to test mode, as described above.
- the network node configurator 138 invokes the traffic simulator 305 to apply simulated network traffic to the duplicate softswitch 205 to validate the updated TSN schedule, as described above.
- the simulated network traffic is obtained from the simulated network traffic repository included in the repositories 146 (represented by block 1326 in FIG. 14 ).
- the simulated network traffic is collected by one or more virtual network sinks which determine traffic performance metrics associated with the simulated network traffic processed by the duplicate softswitch 205 based on the updated TSN schedule (block 1328 ).
- the network node configurator 138 also monitors switch metrics associated with processing of the simulated network traffic by the duplicate softswitch 205 , as described above.
- processing proceeds to block 1334 .
- the network node configurator 138 compares, as described above, the monitored metrics with the first set of constraints (e.g., hard constraints) obtained from the workload scheduling and metrics specification repository included in the repositories 146 (represented by block 1336 in FIG. 14 ).
- the network node configurator 138 determines, as described above, whether the first set of constraints (e.g., hard constraints) is met and, thus, whether the updated TSN schedule is valid. If the updated TSN schedule is not valid because one or of the first set of constraints was not met (block 1338 ), then processing returns from the subroutine 1332 (represented by block 1340 in FIG. 14 ).
- the network node configurator 138 adjusts the configuration of the new softswitch 205 to cause one or more of the second set of constraints (e.g., soft constraints) obtained from the workload scheduling and metrics specification repository to be met.
- the network node configurator 138 continues to iteratively adjust perform such constraint optimization until the second set of constraints (e.g., soft constraints) is met or the bounded time limit is met, as described above. Processing then returns from the subroutine 1332 (represented by block 1340 in FIG. 14 ).
- the network node configurator 138 causes processing to proceed to block 1348 if the updated TSN schedule is determined not to be valid, and causes processing to proceed to block 1350 if the updated TSN schedule is determined to be valid.
- the network node configurator 138 generates a deployment failure message and transmits the failure message to the central configuration controller 102 , as described above.
- the orchestrator 150 and the central user configurator 152 receive the deployment failure message.
- the orchestrator 150 and the central user configurator 152 deletes the VM 142 implementing the workload 140 and the updated TSN schedule, as described above.
- the network node configurator 138 adds respective new port connections to the corresponding existing VMs/containers 128 , 130 , 132 implementing the existing workloads 108 , 110 , 112 on the compute node 104 , binds the new port connections of the VMs/containers 128 , 130 , 132 to the new softswitch 205 , and deletes the prior port connections of the VMs/containers 128 , 130 , 132 that connected to the softswitch 106 , as described above.
- the network node configurator 138 deletes the softswitch 106 from the compute node 104 , as described above, and deletes the configuration specification for the softswitch 106 from the softswitch specification repository included in the repositories 146 (represented by block 1360 of FIG. 13 .)
- the network node configurator 138 invokes the traffic simulator 305 to monitor, as described above, the network traffic processed by the new softswitch 205 based on the updated TSN schedule to generate new simulated network traffic to store in the simulated network traffic repository included in the repositories 146 (represented by block 1364 of FIG. 13 ).
- FIG. 15 is a block diagram of an example processor platform 1500 structured to execute the instructions of FIGS. 8, 13 and/or 14 to implement the example central configuration controller of FIG. 1 .
- the processor platform 1500 can be, for example, a server, a personal computer, a workstation, a self-learning machine (e.g., a neural network), a mobile device (e.g., a cell phone, a smart phone, a tablet such as an iPad′) or any other type of computing device.
- the processor platform 1500 of the illustrated example includes a processor 1512 .
- the processor 1512 of the illustrated example is hardware.
- the processor 1512 can be implemented by one or more integrated circuits, logic circuits, microprocessors, GPUs, DSPs, or controllers from any desired family or manufacturer.
- the hardware processor 1512 may be a semiconductor based (e.g., silicon based) device.
- the processor 1512 implements the orchestrator 150 , the central user configurator 152 , the central network configurator 154 and the scheduler 156 .
- the processor 1512 of the illustrated example includes a local memory 1513 (e.g., a cache).
- the processor 1512 of the illustrated example is in communication with a main memory including a volatile memory 1514 and a non-volatile memory 1516 via a link 1518 .
- the link 1518 may be implemented by a bus, one or more point-to-point connections, etc., or a combination thereof.
- the volatile memory 1514 may be implemented by Synchronous Dynamic Random Access Memory (SDRAM), Dynamic Random Access Memory (DRAM), RAMBUS® Dynamic Random Access Memory (RDRAM®) and/or any other type of random access memory device.
- the non-volatile memory 1516 may be implemented by flash memory and/or any other desired type of memory device. Access to the main memory 1514 , 1516 is controlled by a memory controller.
- the processor platform 1500 of the illustrated example also includes an interface circuit 1520 .
- the interface circuit 1520 may be implemented by any type of interface standard, such as an Ethernet interface, a universal serial bus (USB), a Bluetooth® interface, a near field communication (NFC) interface, and/or a PCI express interface.
- one or more input devices 1522 are connected to the interface circuit 1520 .
- the input device(s) 1522 permit(s) a user to enter data and/or commands into the processor 1512 .
- the input device(s) can be implemented by, for example, an audio sensor, a microphone, a camera (still or video), a keyboard, a button, a mouse, a touchscreen, a track-pad, a trackball, a trackbar (such as an isopoint), a voice recognition system and/or any other human-machine interface.
- many systems, such as the processor platform 1500 can allow the user to control the computer system and provide data to the computer using physical gestures, such as, but not limited to, hand or body movements, facial expressions, and face recognition.
- One or more output devices 1524 are also connected to the interface circuit 1520 of the illustrated example.
- the output devices 1524 can be implemented, for example, by display devices (e.g., a light emitting diode (LED), an organic light emitting diode (OLED), a liquid crystal display (LCD), a cathode ray tube display (CRT), an in-place switching (IPS) display, a touchscreen, etc.), a tactile output device, a printer and/or speakers(s).
- the interface circuit 1520 of the illustrated example thus, typically includes a graphics driver card, a graphics driver chip and/or a graphics driver processor.
- the interface circuit 1520 of the illustrated example also includes a communication device such as a transmitter, a receiver, a transceiver, a modem, a residential gateway, a wireless access point, and/or a network interface to facilitate exchange of data with external machines (e.g., computing devices of any kind) via a network 1526 , such as the network 145 .
- the communication can be via, for example, an Ethernet connection, a digital subscriber line (DSL) connection, a telephone line connection, a coaxial cable system, a satellite system, a line-of-site wireless system, a cellular telephone system, etc.
- DSL digital subscriber line
- the processor platform 1500 of the illustrated example also includes one or more mass storage devices 1528 for storing software and/or data.
- mass storage devices 1528 include floppy disk drives, hard drive disks, compact disk drives, Blu-ray disk drives, redundant array of independent disks (RAID) systems, and digital versatile disk (DVD) drives.
- the volatile memory 1514 and/or the mass storage device 1528 may store the VIFDs processed by the central configuration controller 102 .
- the machine executable instructions 1532 corresponding to the instructions of FIGS. 8, 13 and/or 14 may be stored in the mass storage device 1528 , in the volatile memory 1514 , in the non-volatile memory 1516 , in the local memory 1513 and/or on a removable non-transitory computer readable storage medium, such as a CD or DVD 1536 .
- FIG. 16 is a block diagram of an example processor platform 1600 structured to execute the instructions of FIGS. 9, 10, 11, 12, 13 and/or 14 to implement the example network node configurator 138 of FIGS. 1-5 and/or 7 .
- the processor platform 1600 can be, for example, a server, a personal computer, a workstation, a self-learning machine (e.g., a neural network), a mobile device (e.g., a cell phone, a smart phone, a tablet such as an iPadTM) or any other type of computing device.
- the processor platform 1600 of the illustrated example includes a processor 1612 .
- the processor 1612 of the illustrated example is hardware.
- the processor 1612 can be implemented by one or more integrated circuits, logic circuits, microprocessors, GPUs, DSPs, or controllers from any desired family or manufacturer.
- the hardware processor 1612 may be a semiconductor based (e.g., silicon based) device.
- the processor 1612 implements the traffic simulator 305 , the softswitch instantiator 705 , the TSN schedule configure 710 , the TSN schedule validator 715 and the softswitch replacer 720 .
- the processor 1612 of the illustrated example includes a local memory 1613 (e.g., a cache).
- the processor 1612 of the illustrated example is in communication with a main memory including a volatile memory 1614 and a non-volatile memory 1616 via a link 1618 .
- the link 1618 may be implemented by a bus, one or more point-to-point connections, etc., or a combination thereof.
- the volatile memory 1614 may be implemented by SDRAM, DRAM, RDRAM® and/or any other type of random access memory device.
- the non-volatile memory 1616 may be implemented by flash memory and/or any other desired type of memory device. Access to the main memory 1614 , 1616 is controlled by a memory controller.
- the processor platform 1600 of the illustrated example also includes an interface circuit 1620 .
- the interface circuit 1620 may be implemented by any type of interface standard, such as an Ethernet interface, a USB, a Bluetooth® interface, an NFC interface, and/or a PCI express interface.
- one or more input devices 1622 are connected to the interface circuit 1620 .
- the input device(s) 1622 permit(s) a user to enter data and/or commands into the processor 1612 .
- the input device(s) can be implemented by, for example, an audio sensor, a microphone, a camera (still or video), a keyboard, a button, a mouse, a touchscreen, a track-pad, a trackball, a trackbar (such as an isopoint), a voice recognition system and/or any other human-machine interface.
- many systems, such as the processor platform 1600 can allow the user to control the computer system and provide data to the computer using physical gestures, such as, but not limited to, hand or body movements, facial expressions, and face recognition.
- One or more output devices 1624 are also connected to the interface circuit 1620 of the illustrated example.
- the output devices 1624 can be implemented, for example, by display devices (e.g., an LED, an OLED, an LCD, a CRT display, an IPS display, a touchscreen, etc.), a tactile output device, a printer and/or speakers(s).
- the interface circuit 1620 of the illustrated example thus, typically includes a graphics driver card, a graphics driver chip and/or a graphics driver processor.
- the interface circuit 1620 of the illustrated example also includes a communication device such as a transmitter, a receiver, a transceiver, a modem, a residential gateway, a wireless access point, and/or a network interface to facilitate exchange of data with external machines (e.g., computing devices of any kind) via a network 1626 , such as the network 145 .
- the communication can be via, for example, an Ethernet connection, a DSL connection, a telephone line connection, a coaxial cable system, a satellite system, a line-of-site wireless system, a cellular telephone system, etc.
- the processor platform 1600 of the illustrated example also includes one or more mass storage devices 1628 for storing software and/or data.
- mass storage devices 1628 include floppy disk drives, hard drive disks, compact disk drives, Blu-ray disk drives, RAID systems, and DVD drives.
- the volatile memory 1614 and/or the mass storage device 1628 may implement one or more of the repositories 146 .
- the machine executable instructions 1632 corresponding to the instructions of FIGS. 9, 10, 11, 12, 13 and/or 14 may be stored in the mass storage device 1628 , in the volatile memory 1614 , in the non-volatile memory 1616 , in the local memory 1613 and/or on a removable non-transitory computer readable storage medium, such as a CD or DVD 1636 .
- example methods, apparatus and articles of manufacture have been disclosed that change a TSN schedule implemented by a softswitch on a compute node operating in a time sensitive network.
- Disclosed example methods, apparatus and articles of manufacture improve the efficiency of the compute node by using a duplicate softswitch, also referred to herein as a digital twin softswitch, to enable dynamic changing of the existing TSN schedule implemented by the softswitch executing on the compute node, which may be caused by a new workload being deployed in the time sensitive network, without impacting the deterministic and real-time packet communications associated with existing workloads connected to the softswitch.
- Disclosed example methods, apparatus and articles of manufacture also utilize the duplicate softswitch (digital twin softswitch) to validate an updated TSN schedule in situ with a new workload being deployed, and can prevent deployment of the updated TSN schedule if a performance issue is detected. Disclosed methods, apparatus and articles of manufacture are accordingly directed to one or more improvement(s) in the functioning of a computer.
- duplicate softswitch digital twin softswitch
- the foregoing disclosure provides example solutions to change a time sensitive networking schedule implemented by a softswitch.
- the following further examples which include subject matter such as at least one softswitch time sensitive networking schedule changing apparatus, at least one non-transitory computer readable medium including instructions that, when executed, cause at least one processor to change a time sensitive networking schedule implemented by a softswitch, and a softswitch time sensitive networking schedule changing method, are disclosed herein. Disclosed examples can be implemented individually and/or in one or more combinations.
- Example 1 is an apparatus to change a time sensitive networking schedule implemented by a first softswitch on a compute node.
- the apparatus of example 1 includes a network node configurator and a traffic simulator.
- the network node configurator of example 1 is to (i) deploy a second softswitch on the compute node based on a first configuration specification associated with the first softswitch, (ii) configure the second softswitch to implement an updated time sensitive networking schedule different from the time sensitive networking schedule implemented by the first softswitch, and (iii) replace the first softswitch with the second softswitch in response to a determination that a first set of constraints is met for simulated network traffic processed by the second softswitch based on the updated time sensitive networking schedule.
- the traffic simulator of example 1 is to apply the simulated network traffic to the second softswitch.
- Example 2 includes the subject matter of example 1, wherein the first softswitch is to communicate with respective first ports of corresponding ones of a first set of virtual machines on the compute node to provide the first set of virtual machines with access to a network that implements time sensitive networking, and to replace the first softswitch with the second softswitch, the network node configurator is to: (i) connect the second softswitch to a network interface of the compute node; (ii) add respective second ports to corresponding ones of the first set of virtual machines; (iii) bind the respective second ports of the corresponding ones of the first set of virtual machines to the second softswitch; (iv) delete the respective first ports of the corresponding ones of the first set of virtual machines; and (v) delete the first softswitch from the compute node.
- Example 3 includes the subject matter of example 1 or example 2, wherein the updated time sensitive networking schedule is to support deployment of a new virtual machine to the compute node to host a workload, and the network node configurator is to: (i) connect a port of the new virtual machine to the second softswitch; (ii) configure the workload to operate in a test mode; (iii) monitor a metric associated with the simulated network traffic processed by the second softswitch; and (iv) configure the workload to operate in an operational mode after the determination that the first set of constraints is met for the simulated network traffic processed by the second softswitch based on the updated time sensitive networking schedule.
- Example 4 includes the subject matter of example 3, wherein the simulated network traffic includes: (i) first simulated network traffic associated with a first set of virtual machines on the compute node, the first set of virtual machines in communication with the first softswitch, the first simulated traffic corresponding to previously monitored network traffic obtained during operation of the first set of virtual machines; and (ii) second simulated network traffic associated with the new virtual machine.
- Example 5 includes the subject matter of any one of examples 1 to 4, wherein the network node configurator is to delete the second softswitch and the updated time sensitive networking schedule from the compute node in response to a determination that the first set of constraints is not met for the simulated network traffic processed by the second softswitch based on the updated time sensitive networking schedule.
- Example 6 includes the subject matter of any one of examples 1 to 5, wherein the second softswitch is associated with a second configuration specification, the second configuration specification to correspond to the first configuration specification when the second softswitch is initially deployed on the compute node, and in response to the determination that the first set of constraints is met for the simulated network traffic, the network node configurator is to adjust the second configuration of the second softswitch to satisfy at least one of a second set of constraints to be met for the simulated network traffic processed by the second softswitch based on the updated time sensitive networking schedule.
- Example 7 includes the subject matter of example 6, wherein the network node configurator is to iteratively adjust the second configuration of the second softswitch to satisfy other ones of the second set of constraints to be met for the simulated network traffic until a time limit is reached.
- Example 8 is at least one non-transitory computer readable medium comprising computer readable instructions which, when executed, cause at least one processor to at least: (i) deploy a second softswitch on a compute node based on a first configuration specification associated with a first softswitch on the compute node; (ii) configure the second softswitch to implement a second time sensitive networking schedule different from a first time sensitive networking schedule implemented by the first softswitch; and (iii) replace the first softswitch with the second softswitch in response to a determination that a first set of constraints is met for simulated network traffic processed by the second softswitch based on the second time sensitive networking schedule.
- Example 9 includes the subject matter of example 8, wherein the first softswitch is to communicate with respective first ports of corresponding ones of a first set of virtual machines on the compute node to provide the first set of virtual machines with access to a network that implements time sensitive networking, and to replace the first softswitch with the second softswitch, the instructions, when executed, cause the at least one processor to: (i) connect the second softswitch to a network interface of the compute node; (ii) add respective second ports to corresponding ones of the first set of virtual machines; (iii) bind the respective second ports of the corresponding ones of the first set of virtual machines to the second softswitch; (iv) delete the respective first ports of the corresponding ones of the first set of virtual machines; and (v) delete the first softswitch from the compute node.
- Example 10 includes the subject matter of example 8 or example 9, wherein the second time sensitive networking schedule is to support deployment of a new virtual machine to the compute node to host a workload, and the instructions, when executed, cause the at least one processor to: (i) connect a port of the new virtual machine to the second softswitch; (ii) configure the workload to operate in a test mode; (iii) monitor a metric associated with the simulated network traffic processed by the second softswitch; and (iv) configure the workload to operate in an operational mode after the determination that the first set of constraints is met for the simulated network traffic processed by the second softswitch based on the second time sensitive networking schedule.
- Example 11 includes the subject matter of example 10, wherein the simulated network traffic includes: (i) first simulated network traffic associated with a first set of virtual machines on the compute node, the first set of virtual machines in communication with the first softswitch, the first simulated traffic corresponding to previously monitored network traffic obtained during operation of the first set of virtual machines; and (ii) second simulated network traffic associated with the new virtual machine.
- Example 12 includes the subject matter of any one of examples 8 to 11, wherein the instructions, when executed, cause the at least one processor to delete the second softswitch and the second time sensitive networking schedule from the compute node in response to a determination that the first set of constraints is not met for the simulated network traffic processed by the second softswitch based on the second time sensitive networking schedule.
- Example 13 includes the subject matter of any one of examples 8 to 12, wherein the second softswitch is associated with a second configuration specification, the second configuration specification to correspond to the first configuration specification when the second softswitch is initially deployed on the compute node, and in response to the determination that the first set of constraints is met for the simulated network traffic, the instructions, when executed, cause the at least one processor to adjust the second configuration of the second softswitch to satisfy at least one of a second set of constraints to be met for the simulated network traffic processed by the second softswitch based on the second time sensitive networking schedule.
- Example 14 includes the subject matter of example 13, wherein the instructions, when executed, cause the at least one processor to iteratively adjust the second configuration of the second softswitch to satisfy other ones of the second set of constraints to be met for the simulated network traffic until a time limit is reached.
- Example 15 is a method to change a time sensitive networking schedule implemented by a first softswitch on a compute node.
- the method of claim 15 includes deploying a second softswitch on the compute node based on a first configuration specification associated with the first softswitch.
- the method of claim 15 also includes configuring the second softswitch to implement an updated time sensitive networking schedule different from the time sensitive networking schedule implemented by the first softswitch.
- the method of claim 15 further includes replacing the first softswitch with the second softswitch in response to a determination that a first set of constraints is met for simulated network traffic processed by the second softswitch based on the updated time sensitive networking schedule.
- Example 16 includes the subject matter of example 15, wherein the first softswitch is to communicate with respective first ports of corresponding ones of a first set of virtual machines on the compute node to provide the first set of virtual machines with access to a network that implements time sensitive networking, and replacing the first softswitch with the second softswitch includes: (i) connecting the second softswitch to a network interface of the compute node; (ii) adding respective second ports to corresponding ones of the first set of virtual machines; (iii) binding the respective second ports of the corresponding ones of the first set of virtual machines to the second softswitch; (iv) deleting the respective first ports of the corresponding ones of the first set of virtual machines; and (v) deleting the first softswitch from the compute node.
- Example 17 includes the subject matter of example 15 or example 16, wherein the updated time sensitive networking schedule is to support deployment of a new virtual machine to the compute node to host a workload, and further including: (i) connecting a port of the new virtual machine to the second softswitch; (ii) configuring the workload to operate in a test mode; (iii) monitoring a metric associated with the simulated network traffic processed by the second softswitch; and (iv) configuring the workload to operate in an operational mode after the determination that the first set of constraints is met for the simulated network traffic processed by the second softswitch based on the updated time sensitive networking schedule.
- Example 18 includes the subject matter of example 17, wherein the simulated network traffic includes: (i) first simulated network traffic associated with a first set of virtual machines on the compute node, the first set of virtual machines in communication with the first softswitch, the first simulated traffic corresponding to previously monitored network traffic obtained during operation of the first set of virtual machines; and (ii) second simulated network traffic associated with the new virtual machine.
- Example 19 includes the subject matter of any one of examples 15 to 18, and further includes deleting the second softswitch and the updated time sensitive networking schedule from the compute node in response to a determination that the first set of constraints is not met for the simulated network traffic processed by the second softswitch based on the updated time sensitive networking schedule.
- Example 20 includes the subject matter of any one of examples 15 to 19, wherein the second softswitch is associated with a second configuration specification, the second configuration specification to correspond to the first configuration specification when the second softswitch is initially deployed on the compute node, and in response to the determination that the first set of constraints is met for the simulated network traffic, further including adjusting the second configuration of the second softswitch to satisfy at least one of a second set of constraints to be met for the simulated network traffic processed by the second softswitch based on the updated time sensitive networking schedule.
- Example 21 includes the subject matter of example 20, and further includes iteratively adjusting the second configuration of the second softswitch to satisfy other ones of the second set of constraints to be met for the simulated network traffic until a time limit is reached.
- Example 22 is an apparatus including means for replacing a first softswitch implementing a first time sensitive networking schedule on a compute node with a second softswitch implementing a second time sensitive networking schedule different from the first time sensitive networking schedule, the means for replacing to: (i) deploy the second softswitch on the compute node based on a first configuration specification associated with the first softswitch; (ii) configure the second softswitch to implement the second time sensitive networking schedule; and (iii) replace the first softswitch with the second softswitch in response to a determination that a first set of constraints is met for simulated network traffic processed by the second softswitch based on the second time sensitive networking schedule.
- the apparatus of example 22 also includes means for applying the simulated network traffic to the second softswitch.
- Example 23 includes the subject matter of example 22, wherein the first softswitch is to communicate with respective first ports of corresponding ones of a first set of virtual machines on the compute node to provide the first set of virtual machines with access to a network that implements time sensitive networking, and the means for replacing is to: (i) connect the second softswitch to a network interface of the compute node; (ii) add respective second ports to corresponding ones of the first set of virtual machines; (iii) bind the respective second ports of the corresponding ones of the first set of virtual machines to the second softswitch; (iv) delete the respective first ports of the corresponding ones of the first set of virtual machines; and (v) delete the first softswitch from the compute node.
- Example 24 includes the subject matter of example 22 or example 23, wherein the second time sensitive networking schedule is to support deployment of a new virtual machine to the compute node to host a workload, and the means for replacing is to: (i) connect a port of the new virtual machine to the second softswitch; (ii) configure the workload to operate in a test mode; (iii) monitor a metric associated with the simulated network traffic processed by the second softswitch; and (iv) configure the workload to operate in an operational mode after the determination that the first set of constraints is met for the simulated network traffic processed by the second softswitch based on the second time sensitive networking schedule.
- Example 25 includes the subject matter of example 24, wherein the simulated network traffic includes: (i) first simulated network traffic associated with a first set of virtual machines on the compute node, the first set of virtual machines in communication with the first softswitch, the first simulated traffic corresponding to previously monitored network traffic obtained during operation of the first set of virtual machines; and (ii) second simulated network traffic associated with the new virtual machine.
- Example 26 includes the subject matter of any one of examples 22 to 25, wherein the means for replacing is to delete the second softswitch and the second time sensitive networking schedule from the compute node in response to a determination that the first set of constraints is not met for the simulated network traffic processed by the second softswitch based on the second time sensitive networking schedule.
- Example 27 includes the subject matter of any one of examples 22 to 26, wherein the second softswitch is associated with a second configuration specification, the second configuration specification to correspond to the first configuration specification when the second softswitch is initially deployed on the compute node, and in response to the determination that the first set of constraints is met for the simulated network traffic, the means for replacing is to adjust the second configuration of the second softswitch to satisfy at least one of a second set of constraints to be met for the simulated network traffic processed by the second softswitch based on the second time sensitive networking schedule.
- Example 28 includes the subject matter of example 27, wherein the means for replacing is to iteratively adjust the second configuration of the second softswitch to satisfy other ones of the second set of constraints to be met for the simulated network traffic until a time limit is reached.
- Example 29 is an apparatus to change a time sensitive networking schedule implemented by a softswitch on a compute node.
- the apparatus of example 29 includes a central user configurator to parse a virtualized industrial function descriptor corresponding to a virtualized workload to determine a set of parameters for an updated time sensitive networking schedule to be implemented by the softswitch.
- the apparatus of example 29 also includes a central network configurator to: (i) determine the updated time sensitive networking schedule based on the set of parameters; and (ii) send the updated time sensitive networking schedule to the compute node.
- Example 30 includes the subject matter of example 29, and further includes an orchestrator to parse the virtualized industrial function descriptor to determine a virtual machine configuration specification for a virtual machine to deploy on the compute node to host the virtualized workload, and to send the virtual machine configuration specification to the compute node to cause the virtual machine to be deployed on the compute node.
- an orchestrator to parse the virtualized industrial function descriptor to determine a virtual machine configuration specification for a virtual machine to deploy on the compute node to host the virtualized workload, and to send the virtual machine configuration specification to the compute node to cause the virtual machine to be deployed on the compute node.
- Example 31 includes the subject matter of example 30, wherein the orchestrator is to delete the virtual machine from the compute node in response to a message from the compute node indicating a first set of constraints is not met by the updated time sensitive networking schedule.
- Example 32 includes the subject matter of any one of examples 29 to 31, wherein the central user configurator is to delete the updated time sensitive networking schedule in response to a message from the compute node indicating a first set of constraints is not met by the updated time sensitive networking schedule.
- Example 33 includes the subject matter of any one of examples 29 to 32, wherein the central user configurator is to: (i) determine whether the central network configurator supports generation of the updated time sensitive networking schedule based on a first one of the set of parameters; and (ii) discard the first one of the set of parameters when the central network configurator does not support generation of the updated time sensitive networking schedule based on the first one of the set of parameters.
- Example 34 includes the subject matter of any one of examples 29 to 32, wherein the central user configurator is to: (i) determine whether the central network configurator supports generation of the updated time sensitive networking schedule based on a first one of the set of parameters; and (ii) replace the first one of the set of parameters with a different parameter when the central network configurator does not support generation of the updated time sensitive networking schedule based on the first one of the set of parameters.
- Example 35 is at least one non-transitory computer readable medium comprising computer readable instructions which, when executed, cause at least one processor to at least: (i) parse a virtualized industrial function descriptor corresponding to a virtualized workload to determine a set of parameters for a second time sensitive networking schedule to be implemented by a softswitch on a compute node, the second time sensitive networking schedule different from a first time sensitive networking schedule already implemented by the softswitch on the compute node; (ii) determine the second time sensitive networking schedule based on the set of parameters; and (iii) send the second time sensitive networking schedule to the compute node.
- Example 36 includes the subject matter of example 35, wherein the instructions, when executed, cause the at least one processor to: (i) parse the virtualized industrial function descriptor to determine a virtual machine configuration specification for a virtual machine to deploy on the compute node to host the virtualized workload; and (ii) send the virtual machine configuration specification to the compute node to cause the virtual machine to be deployed on the compute node.
- Example 37 includes the subject matter of example 36, wherein the instructions, when executed, further cause the at least one processor to delete the virtual machine from the compute node in response to a message from the compute node indicating a first set of constraints is not met by the second time sensitive networking schedule.
- Example 38 includes the subject matter of example 35 or example 36, wherein the instructions, when executed, cause the at least one processor to delete the second time sensitive networking schedule in response to a message from the compute node indicating a first set of constraints is not met by the second time sensitive networking schedule.
- Example 39 is a method to change a time sensitive networking schedule implemented by a softswitch on a compute node.
- the method of example 39 includes parsing a virtualized industrial function descriptor corresponding to a virtualized workload to determine a set of parameters for an updated time sensitive networking schedule to be implemented by the softswitch.
- the method of example 39 also includes determining the updated time sensitive networking schedule based on the set of parameters.
- the method of example 39 further includes sending the updated time sensitive networking schedule to the compute node.
- Example 40 includes the subject matter of example 39, and further includes (i) parsing the virtualized industrial function descriptor to determine a virtual machine configuration specification for a virtual machine to deploy on the compute node to host the virtualized workload; and (ii) sending the virtual machine configuration specification to the compute node to cause the virtual machine to be deployed on the compute node.
- Example 41 includes the subject matter of example 40, and further includes deleting the virtual machine from the compute node in response to a message from the compute node indicating a first set of constraints is not met by the updated time sensitive networking schedule.
- Example 42 includes the subject matter of example 39 or example 40, and further includes deleting the updated time sensitive networking schedule in response to a message from the compute node indicating a first set of constraints is not met by the updated time sensitive networking schedule.
- Example 43 is an apparatus including means for parsing a virtualized industrial function descriptor corresponding to a virtualized workload to determine a set of parameters for a second time sensitive networking schedule to be implemented by a softswitch on a compute node, the second time sensitive networking schedule different from a first time sensitive networking schedule already implemented by the softswitch on the compute node.
- the apparatus of example 43 also includes means for determining the second time sensitive networking schedule based on the set of parameters, the means for determining the second time sensitive networking schedule to send the second time sensitive networking schedule to the compute node.
- Example 44 includes the subject matter of example 43, and further includes means for determining a virtual machine configuration specification for a virtual machine to deploy on the compute node to host the virtualized workload, the means for determining the virtual machine configuration specification to: (i) parse the virtualized industrial function descriptor to determine the virtual machine configuration specification; and (ii) send the virtual machine configuration specification to the compute node to cause the virtual machine to be deployed on the compute node.
- Example 45 includes the subject matter of example 44, wherein the means for determining the virtual machine configuration specification is further to delete the virtual machine from the compute node in response to a message from the compute node indicating a first set of constraints is not met by the updated time sensitive networking schedule.
- Example 46 includes the subject matter of example 43 or example 44, wherein the means for determining the second time sensitive networking schedule is further to delete the second time sensitive networking schedule in response to a message from the compute node indicating a first set of constraints is not met by the second time sensitive networking schedule.
- Example 47 includes the subject matter of any one of examples 1 to 7, wherein the second softswitch is a duplicate of the first softswitch when the second softswitch is initially deployed on the compute node by the network node configurator.
- Example 48 includes the subject matter of any one of examples 8 to 14, wherein the second softswitch is a duplicate of the first softswitch when the second softswitch is initially deployed on the compute node.
- Example 49 includes the subject matter of any one of examples 15 to 21, wherein the second softswitch is a duplicate of the first softswitch when the second softswitch is initially deployed on the compute node.
- Example 50 includes the subject matter of any one of examples 22 to 28, wherein the second softswitch is a duplicate of the first softswitch when the second softswitch is initially deployed on the compute node.
Abstract
Description
- This disclosure relates generally to time sensitive networking and, more particularly, to changing a time sensitive networking schedule implemented by a softswitch.
- Time sensitive networks include network devices (also referred to herein as network elements) that interoperate to provide, among other things, time synchronization and packet scheduling to, for example, ensure one or more latency targets for packets sent from one network device to another network device are met. For example, industrial control applications may rely on such network latency target(s) being met to achieve proper operation of the industrial equipment being controlled. Time sensitive networks utilize a time sensitive networking schedule that is created based on the actual topology of the network and application latency requirements. The time sensitive networking schedule is implemented by the network devices. When the network topology changes and/or new applications are deployed in the time sensitive network, an updated time sensitive networking schedule is created and provided to the network devices for implementation.
-
FIG. 1 is a block diagram of an example environment of use including an example central configuration controller and an example network node configurator to change a time sensitive networking schedule implemented by an example softswitch of a compute node in accordance with teachings of this disclosure. -
FIGS. 2-5 illustrate an example procedure performed by the example network node configurator of the example compute node ofFIG. 1 to change the time sensitive networking schedule implemented by the softswitch of the compute node in accordance with teachings of this disclosure. -
FIG. 6 illustrates an example virtualized industrial function descriptor processed by the central configuration controller ofFIG. 1 . -
FIG. 7 is a block diagram of an example implementation of the network node configurator ofFIGS. 1-5 . -
FIG. 8 is a flowchart representative of example computer readable instructions that may be executed to implement the example central configuration controller ofFIG. 1 . -
FIGS. 9-12 are flowcharts and pseudocode representative of example computer readable instructions that may be executed to implement the example network node configurator ofFIGS. 1-5 and/or 7 . -
FIGS. 13-14 collectively illustrated a flowchart representative of example computer readable instructions that may be executed to implement the example central configuration controller ofFIG. 1 and the example network node configurator ofFIGS. 1-5 and/or 7 . -
FIG. 15 is a block diagram of an example processor platform structured to execute the example computer readable instructions ofFIGS. 8, 13 and/or 14 to implement the example central configuration controller ofFIG. 1 . -
FIG. 16 is a block diagram of an example processor platform structured to execute the example computer readable instructions ofFIGS. 9, 10, 11, 12, 13 and/or 14 to implement the example network node configurator ofFIGS. 1-5 and/or 7 . - The figures are not to scale. In general, the same reference numbers will be used throughout the drawing(s) and accompanying written description to refer to the same or like parts, elements, etc. Connection references (e.g., attached, coupled, connected, and joined) are to be construed broadly and may include intermediate members between a collection of elements and relative movement between elements unless otherwise indicated. As such, connection references do not necessarily infer that two elements are directly connected and in fixed relation to each other.
- Descriptors “first,” “second,” “third,” etc. are used herein when identifying multiple elements or components which may be referred to separately. Unless otherwise specified or understood based on their context of use, such descriptors are not intended to impute any meaning of priority, physical order or arrangement in a list, or ordering in time but are merely used as labels for referring to multiple elements or components separately for ease of understanding the disclosed examples. In some examples, the descriptor “first” may be used to refer to an element in the detailed description, while the same element may be referred to in a claim with a different descriptor such as “second” or “third.” In such instances, it should be understood that such descriptors are used merely for ease of referencing multiple elements or components.
- Example methods, apparatus, systems and articles of manufacture (e.g., physical storage media) to change a time sensitive networking schedule implemented by a softswitch are disclosed herein. Example apparatus disclosed herein to change a time sensitive networking schedule implemented by a first softswitch on a compute node include an example network node configurator to deploy a second softswitch on the compute node based on a first configuration specification associated with the first softswitch. The example network node configurator is also to configure the second softswitch to implement an updated time sensitive networking schedule different from the time sensitive networking schedule implemented by the first softswitch. The example network node configurator is further to replace the first softswitch with the second softswitch in response to a determination that a first set of constraints is met for simulated network traffic processed by the second softswitch based on the updated time sensitive networking schedule. Such disclosed example apparatus also include an example traffic simulator to apply the simulated network traffic to the second softswitch.
- In some disclosed examples, the first softswitch is to communicate with respective first ports (also referred to herein as port connections) of corresponding ones of a first set of virtual machines on the compute node to provide the first set of virtual machines with access to a network that implements time sensitive networking. In some such disclosed examples, to replace the first softswitch with the second softswitch, the network node configurator is to: (i) connect the second softswitch to a network interface of the compute node, (ii) add respective second ports to corresponding ones of the first set of virtual machines, (iii) bind the respective second ports of the corresponding ones of the first set of virtual machines to the second softswitch, (iv) delete the respective first ports of the corresponding ones of the first set of virtual machines, and (v) delete the first softswitch from the compute node.
- In some disclosed examples, the updated time sensitive networking schedule is to support deployment of a new virtual machine, which hosts a latency sensitive workload, to the compute node. In some such disclosed examples, the network node configurator is to: (i) connect a port of the new virtual machine to the second softswitch, (ii) configure the workload to operate in a test mode, (iii) monitor metrics associated with the simulated network traffic processed by the second softswitch, and (iv) configure the workload to operate in an operational mode after the determination that the first set of constraints is met for the simulated network traffic processed by the second softswitch based on the updated time sensitive networking schedule. In some such disclosed examples, the simulated network traffic includes first simulated network traffic associated with a first set of virtual machines on the compute node and second simulated network traffic associated with the new virtual machine. For example, the first set of virtual machines may be in communication with the first softswitch, and the first simulated traffic may correspond to previously monitored network traffic obtained during operation of the first set of virtual machines.
- In some disclosed examples, the network node configurator is to delete the second softswitch and the updated time sensitive networking schedule from the compute node in response to a determination that the first set of constraints is not met for the simulated network traffic processed by the second softswitch based on the updated time sensitive networking schedule.
- In some disclosed examples, the second softswitch is associated with a second configuration specification, which is to correspond with the first configuration specification when the second softswitch is initially deployed on the compute node. In some such examples, in response to the determination that the first set of constraints is met for the simulated network traffic, the network node configurator is to adjust the second configuration of the second softswitch to satisfy at least one of a second set of constraints to be met for the simulated network traffic processed by the second softswitch based on the updated time sensitive networking schedule. For example, the network node configurator may iteratively adjust the second configuration of the second softswitch to satisfy other ones of the second set of constraints to be met for the simulated network traffic until a time limit is reached.
- Other example apparatus disclosed herein to change a time sensitive networking schedule implemented by a softswitch on a compute node include an example central user configurator to parse a virtualized industrial function descriptor corresponding to a virtualized workload to determine a set of parameters for an updated time sensitive networking schedule to be implemented by the softswitch. Such disclosed example apparatus also include an example central network configurator to determine the updated time sensitive networking schedule based on the set of parameters, and send the updated time sensitive networking schedule to the compute node.
- Some such disclosed example apparatus also include an example orchestrator to parse the virtualized industrial function descriptor to determine a virtual machine configuration specification for a virtual machine to deploy on the compute node to host the virtualized workload. In some examples, the orchestrator is to send the virtual machine configuration specification to the compute node to cause the virtual machine to be deployed on the compute node. In some examples, the orchestrator is further to delete the virtual machine from the compute node in response to a message from the compute node indicating a first set of constraints is not met by the updated time sensitive networking schedule.
- In some disclosed examples, the central user configurator is to delete the updated time sensitive networking schedule in response to a message from the compute node indicating a first set of constraints is not met by the updated time sensitive networking schedule.
- In some disclosed examples, the central user configurator is to determine whether the central network configurator supports generation of the updated time sensitive networking schedule based on a first one of the set of parameters. In some such examples, the central user configurator is to discard the first one of the set of parameters, or replace the first one of the set of parameters with a different parameter, when the central network configurator does not support generation of the updated time sensitive networking schedule based on the first one of the set of parameters.
- These and other example methods, apparatus, systems and articles of manufacture (e.g., physical storage media) to change a time sensitive networking schedule implemented by a softswitch are disclosed in further detail below.
- As mentioned above, time sensitive networks include network elements that interoperate to provide, among other things, time synchronization and scheduling to, for example, ensure one or more latency targets for packets sent from one network element to another network element are met. For example, network elements that implement a time sensitive network may be structured to implement a time sensitive networking (TSN) schedule in accordance with a defined standard, such as the Institute of Electrical and Electronics Engineers (IEEE) 802.1Qbv Standard, published on Mar. 18, 2016. The TSN schedule specified by the IEEE 802.1Qbv Standard utilizes a gate structure and corresponding packet classifications to support strictly timed packet transmission slots. Interest in time sensitive networks is increasing due to their ability to ensure packet latency targets are met on an open standards-based network (as compared to a proprietary network). For example, industrial control applications may rely on deterministic packet latency distributions with a known upper latency bound (e.g., such as 31.25 microseconds, or some other bound) for the isochronous, real-time network traffic generated by a given control function, such as a programmable logic controller (PLC), a motion controller, a numerical controller, etc.
- There is also interest in the use of softswitches to implement network elements that provide access to an underlying network. For example, the use of softswitches in cloud computing environments is becoming the norm. A softswitch can be a virtual switch that is implemented by one or more virtual network functions (VNFs) that execute on a compute node, such as a server, a router, a cloud host, etc. As such, the terms softswitch, virtual switch, vSwitch, etc., are synonymous and can be used interchangeably unless noted otherwise For example, interest in the use of softswitches in industrial applications is being driven, at least in part, by customer interest in the use of virtualized industrial functions (VIFs) to implement the workloads to control industrial equipment, and in the horizontal consolidation of the VIFs on edge compute nodes located at or near the sites where the equipment is to be controlled. Softswitches can be used in such examples to provide network connectivity between the VIF workloads on a compute node and the external equipment being controlled. Softswitches can also provide network connectivity between the VIF workloads on the compute node itself.
- Thus, in addition to implementing softswitches that support the flexible workload deployments and removal operations associated with such network function virtualization (NFV) environments, there is a need for softswitches that can support TSN. However, existing softswitches may not be able to support TSN, especially for applications, such as industrial control applications, with strict latency targets. For example, in an IEEE 802.1Qbv implementation, the TSN schedule for a given time sensitive network is determined based on the actual topology of the network. When a new VIF workload, with its associated deterministic and real-time packet cycle times, is to be deployed on a customer's edge compute node (or cluster), an updated TSN schedule is created to accommodate that new VIF workload in the network. The updated TSN schedule is deployed to the TSN network endpoints. The TSN network endpoints include the TSN-enabled softswitch executing on that compute node to provide first-hop connectivity to the new VIF workload. Existing softswitch implementations may require stopping the softswitch, applying the updated TSN schedule to the softswitch, and then re-initializing/restarting the softswitch to have the updated TSN schedule take effect at the softswitch.
- However, the sequence of stopping the softswitch, applying the updated TSN schedule to the softswitch, and then re-initializing/restarting the softswitch may cause existing workloads connected to the softswitch to experience packet communication delays and/or dropouts that exceed the latency target (e.g., 31.25 microseconds, or some other target) of the time sensitive network. To address this technical problem, example technical solutions disclosed herein utilize a duplicate softswitch (also referred to herein as a digital twin softswitch) to enable dynamic changing of a TSN schedule implemented by a softswitch without impacting the deterministic and real-time packet communications associated with existing workloads connected to the softswitch. For example, a change of the TSN schedule may be caused by a new workload being deployed in the time sensitive network. As discussed in further detail below, example technical solutions disclosed herein also utilize the duplicate softswitch (digital twin softswitch) to validate an updated TSN schedule in situ with the new workload being deployed, and can prevent deployment of the updated TSN schedule if a performance issue is detected.
- Turning to the figures, a block diagram of an example
central configuration controller 102 and an examplenetwork node configurator 138 structured to change a time sensitive networking schedule implemented by anexample softswitch 106 of acompute node 104 in accordance with teachings of this disclosure is illustrated inFIG. 1 in the context of an example environment ofuse 100. In the illustrated example, thecompute node 104 corresponds to anedge compute node 104 deployed in an industrial environment (e.g., facility, plant, etc.) to executeworkloads physical equipment 114 in the industrial environment. For example, the physical equipment can include a distributed control system (DCS), a physical programmable logic controller (PLC), a gateway, a robot, a tool, vision processing equipment, etc. As such, thecompute node 104 can be implemented by, for example, any appropriate computing device or combination of computing devices, such as a server in an edge cluster, an industrial computer, etc. In some example, thecompute node 104 is implemented by a processor platform such as theexample processor platform 1600 ofFIG. 16 , which is described in further detail below. Although thecompute node 104 of the illustrated example is deployed in an industrial environment, in the other examples, thecompute node 104 can be deployed in other types of environments. For example, thecompute node 104 could correspond to a controller to execute workloads to control fifth generation (5G) small cell sites, cloud center server farms, etc. - In the
example environment 100 ofFIG. 1 , thecompute node 104 communicates with thephysical equipment 114 via an example timesensitive network 116. In the illustrated example, the timesensitive network 116 connects thecompute node 104 with thephysical equipment 114 and, in some examples, other example compute node(s) 118 via anexample bridge 120. Thebridge 120 can be implemented by any network bridge, router, server, device, etc., capable of implementing a TSN schedule (e.g., a TSN schedule in accordance with the IEEE 802.1Qbv Standard). Each of the compute node(s) 118 of the illustrated example can be implemented by any appropriate computing device or combination of computing devices, such as a server in an edge cluster, an industrial computer, etc., which may be similar to, or different from, thecomputing node 104. - To connect to the time
sensitive network 116, thecompute node 104 include an example network interface card (MC) 122. Likewise, the compute node(s) 118 includerespective NICs 124. TheNICs sensitive network 116. For example, if the timesensitive network 116 is a wired network, such as an Ethernet network, a digital subscriber line (DSL) network, etc., theNICs sensitive network 116 is a wireless network, such as a wireless local area network (WLAN), a cellular network, etc., theNICs FIG. 1 , thesoftswitch 106 implemented on thecompute node 104 communicates with theNIC 122 of thecompute node 104 via an example data plane development kit (DPDK) 126. The DPDK provides a set of libraries to enable efficient communication of data packets between the softswitch 106 and theNIC 122. - The
softswitch 106 of thecompute node 104 corresponds to a virtual switch implemented by one or more virtual network functions (VNFs) to provide theworkloads compute node 104 with access to the timesensitive network 116, which connects theworkloads physical equipment 114. In some examples, thesoftswitch 106 also implements an exampleinternal network 127 to allow some or all of theworkloads compute node 104. Theworkloads physical equipment 114, monitor thephysical equipment 114, process data returned by thephysical equipment 114 for use in other applications, etc. For example, theworkloads virtual PLCs workload 112 of the illustrated example corresponds to avision processing workload 112, which is a non-deterministic workload to perform computer vision processing on data returned from one or more of thephysical equipment 114. Thus, thesoftswitch 106 can support deterministic and non-deterministic workloads. In the illustrated example ofFIG. 1 , theworkloads softswitch 106. For example, theworkloads respective example VMs workload 112 is hosted by anexample container 132. As shown in the example ofFIG. 1 , theVMs VMs softswitch 106. - The
softswitch 106 of the illustrated example implements a TSN schedule, such as a TSN schedule compliant with the IEEE 802.1Qbv Standard, to transmit and receive data packets as part of the timesensitive network 116. For example, thesoftswitch 106 may include multiple data buffers (e.g., queues) assigned to different data classes defined by the TSN schedule, which thesoftswitch 106 gates on and off to provide access to the timesensitive network 116 to meet timing requirements specified by the TSN schedule. To configure thesoftswitch 106 to implement a TSN schedule deployed to thecompute node 104, thecompute node 104 includes the examplenetwork node configurator 138. The other compute node(s) 118 also include respective example network node configurator(s) 139. As disclosed in further detail below, thenetwork node configurator 138 is also responsible for changing the TSN schedule implemented by thesoftswitch 106 when an updated TSN schedule is deployed to thecompute node 104. Thenetwork node configurator 138 is also responsible for validating the updated TSN schedule before deploying the updated TSN schedule for softswitch implementation. For example, an updated TSN schedule may be deployed to thecompute node 104 when a new workload, such as anexample workload 140, is to be deployed to thecompute node 104 for execution. As shown inFIG. 1 , theworkload 140 may be similar to, or different from, theworkloads example VM 142 with anexample VNIC 144. As described in further detail below, the updated TSN schedule is created to accommodate the packet communication timing requirements of thenew workload 140 to be deployed on thecompute node 104, as well as the packet communication timing requirements of existing workloads operating in the timesensitive network 116, such as theworkloads network node configurator 138 utilizes one or moreexample data repositories 146 to configure thesoftswitch 106 to implement a TSN schedule, to change the TSN schedule implemented by thesoftswitch 106, to confirm that an updated TSN schedule is viable before deploying the updated TSN schedule for softswitch implementation, etc. Thedata repositories 146 can be implemented by any number and/or type(s) of storage devices, memories, etc. For example, thedata repositories 146 can be implemented by the examplevolatile memory 1614 and/or the example mass storage device(s) 1628 ofFIG. 16 , which are described in further detail below. - The
central configuration controller 102 is included in theexample environment 100 to deploy workloads and TSN schedules to thecompute nodes sensitive network 116. As such, thecentral configuration controller 102 communicates with thecompute nodes example network 148. Thenetwork 148 can be implemented by any number and/or type(s) of communication networks. For example, the communication network 125 can be implemented by one or more wired/cabled networks, one or more wireless networks (e.g., mobile cellular networks, satellite networks, etc.), one or more proprietary networks, one or more public networks (e.g., such as the Internet), etc., or any combination thereof. In the illustrated example, thenetwork 148 is different from the timesensitive network 116 that connects thecompute nodes physical equipment 114. - The
central configuration controller 102 can be implemented by, for example, any appropriate computing device or combination of computing devices. In some example, thecentral configuration controller 102 is implemented by a processor platform such as theexample processor platform 1500 ofFIG. 15 , which is described in further detail below. In the illustrated example ofFIG. 1 , thecentral configuration controller 102 includes anexample orchestrator 150 to deploy workloads to thecompute nodes central configuration controller 102 of the illustrated example also includes an examplecentral user configurator 152 and an examplecentral network configurator 154 to configure the timesensitive network 116. For example, thecentral network configurator 154 includes anexample scheduler 156 to create TSN schedules to be deployed to thenetwork nodes sensitive network 116. As described in further detail below, the workloads and TSN schedules are created based on example virtualized industrial function descriptors (VIFD) 158 that specify the instantiation parameters, operational behaviors, network communication requirements, etc., for the workloads to be deployed to thecompute nodes central configuration controller 102 and thenetwork node configurator 138 to change a TSN schedule implemented by thesoftswitch 106 of thecompute node 104 is described in further detail below in connection withFIGS. 1-5 . Anexample VIFD 158 is illustrated inFIG. 6 , which is also described in further detail below. - With reference to
FIG. 1 , an example procedure performed by thecentral configuration controller 102 and thenetwork node configurator 138 to change a TSN schedule implemented by thesoftswitch 106 of thecompute node 104 begins with thecentral configuration controller 102 receiving theVIFD 158 for thenew workload 140 to be deployed to thecompute node 104. As noted above, theVIFD 158 specifies the instantiation parameters, operational behaviors, network communication requirements, etc., for thenew workload 140. In some examples, theVIFD 158 is an enhancement of the virtual network function descriptor (VNFD) specified by the European Telecommunications Standards Institute (ETSI) in the specification “Network Functions Virtualisation (NFV) Release 2; Protocols and Data Models; NFV descriptors based on TOSCA specification,” version 2.5.1, published in December 2018. In some such examples, theVIFD 158 is a file that uses the Topology and Orchestration Specification for Cloud Applications (TOSCA) language to specify the instantiation parameters, operational behaviors, network communication requirements, etc., for thenew workload 140. For example, a VNFD uses the TOSCA language to specify the instantiation parameters and operational behaviors of VNF workloads. For example, the VNFD can contain key performance indicators (KPIs) and/or other requirements that can be used in the process of onboarding and managing the lifecycle of the VNF workloads. However, a VNFD does not describe the real-time networking requirements for a workload, such as packet communication jitter targets/bounds, latency targets/bounds, etc. TheVIFD 158 extends the VNFD to include network communication scheduling requirements for theworkload 140, such as frame spacing, mean latency, an upper bound for latency, etc. - An example implementation of the
VIFD 158 is illustrated inFIG. 6 . Theexample VIFD 158 ofFIG. 6 includes an exampletopology definition section 605, which specifies the instantiation parameters and operational behaviors of theworkload 140. Theexample VIFD 158 ofFIG. 6 also includes an example schedulingconstraints definition section 610, which specifies the network communication scheduling requirements for theworkload 140. - Returning to
FIG. 1 , in the illustrated example, theorchestrator 150 and thecentral user configurator 152 read theVIFD 158 for theworkload 140. Theorchestrator 150 parses the VM-related fields of theVIFD 158 to define the resource requirements (e.g. number of virtual central processing units (CPUs), memory, storage, network interfaces, etc.) for theworkload 140 to be deployed (e.g., in real-time) to the compute node 104 (e.g., which may be an edge compute node or cluster in an industrial computer premises system). For example, theorchestrator 150 parses thetopology definition section 605 of theVIFD 158 to determine the parameters (e.g., VM flavor, number of network connections, image name, number of cores, core isolation, core pinning, memory/disk sizes, etc.) to be used by the orchestrator to create a VM configuration specification for theVM 142, which is to host theworkload 140 on thecompute node 104. The orchestrator 150 then creates the VM configuration specification for theVM 142 based on the parameters parsed from theVIFD 158, and sends (e.g., transmits) the VM configuration specification (e.g., via the network 148) to thecompute node 104 to deploy theVM 142 andworkload 140 to thecompute node 104. Accordingly, theorchestrator 150 is an example of means for parsing a virtualized industrial function descriptor to determine a virtual machine configuration specification for a virtual machine to deploy on a compute node to implement a virtualized workload. - In the illustrated example, the
central user configurator 152 parses the scheduling-related fields of theVIFD 158 to determine the network communication scheduling requirements for theworkload 140. For example, thecentral user configurator 152 parses the schedulingconstraints definition section 610 of theVIFD 158 to identify the network communication scheduling parameters specified for theworkload 140, which will be used by thecentral network configurator 154 to create an updated TSN schedule to accommodate theworkload 140 in the timesensitive network 116. In some examples, thecentral user configurator 152 is implemented to meet the functional requirements of a central user configurator in accordance with the IEEE 802.1Qcc Standard, published on Oct. 31, 2018. In some such examples, thecentral user configurator 152 is an architectural component of a TSN environment, and is responsible for the discovery of end stations, retrieving end station capabilities and user requirements, etc. In the illustrated example ofFIG. 1 , thecentral user configurator 152 is responsible for identifying the network communication scheduling parameters specified in theVIFD 158 for theworkload 140, and for transposing the identified network communication scheduling parameters into a parameter set supported by thecentral network configurator 154. In some examples, thecentral user configurator 152 determines whether the network communication scheduling parameters identified in theVIFD 158 for theworkload 140 are supported by thecentral network configurator 154. In some such examples, if an identified network communication scheduling parameter is not supported by thecentral network configurator 154, thecentral user configurator 152 replaces the unsupported parameter with a different parameter (e.g., a nearest approximation) supported by thecentral network configurator 154. In some examples, if an identified network communication scheduling parameter is not supported by thecentral network configurator 154, thecentral user configurator 152 discards the unsupported parameter (e.g., if a suitable substitute is not available). Accordingly, thecentral user configurator 152 is an example of means for parsing a virtualized industrial function descriptor corresponding to a virtualized workload to determine a set of parameters for an updated time sensitive networking schedule to be implemented by one or more softswitches. For example, thecentral user configurator 152 may provide an updated time sensitive networking schedule to one softswitch to address communication requirements among workloads on the compute node associated with that softswitch. In other examples, thecentral user configurator 152 may provide an updated time sensitive networking schedule to multiple softswitches to address communication requirements across the timesensitive network 116 among workloads on different compute nodes associated with the different softswitches. - In the illustrated example, the
central network configurator 154 provides a centralized means for performing resource reservation, scheduling, configuration of thecompute nodes sensitive network 116, etc. In some examples, thecentral network configurator 154 communicates with thecompute nodes bridge 120, etc.), via a remote management protocol, such as the network configuration protocol (NETCONF), RESTCONF, etc. In the illustrated examples, thecentral network configurator 154 includes thescheduler 156 to create an updated TSN schedule based on the set of scheduling parameters provided by the central user configurator 152 (e.g., after any replacing/discarding, as described above) to accommodate thenew workload 140. For example, thescheduler 156 of thecentral network configurator 154 creates the updated TSN schedule that complies with IEEE 802.1Qbv Standard and is intended to meet the real-time, isochronous packet transmission requirements specified in theVIFD 158 for theworkload 140. Accordingly, thecentral network configurator 154 is an example of means for determine an updated TSN schedule based on a set of parameters specified for a virtualized workload. - In the illustrated example, when the updated TSN schedule is ready, it is sent to the
network node configurator 138 of thecompute node 104 for deployment to thesoftswitch 106. For example, the updated TSN schedule may be sent via an end station configuration protocol, which may be based on a publish/subscribe mechanism, such as the OPC unified architecture (OPC-UA) protocol. Turning toFIG. 2 , in response to receiving the updated TSN schedule, thenetwork node configurator 138 creates (e.g., instantiates) anexample duplicate softswitch 205, which is a duplicate or digital twin of the existingsoftswitch 205. Thenetwork node configurator 138 uses theduplicate softswitch 205 to test the updated TSN schedule and, upon successful validation, to apply the new TSN schedule at thecompute node 104 without interruption of the existingworkload softswitch 106. Accordingly, thenetwork node configurator 138 is an example of means for replacing a first softswitch implementing a first (e.g., existing) TSN schedule at a compute node with a second softswitch to implement a second (e.g., updated) TSN schedule at the compute node, which can include deploying the second softswitch on the compute node with an initial configuration based on (e.g., matching) the configuration of the first softswitch, configuring the second softswitch to implement the second (e.g., updated) TSN schedule, and replacing the first softswitch with the second softswitch after validation of the second TSN schedule implemented by the second softswitch. - For example, in response to receiving the updated TSN schedule, the
network node configurator 138 accesses a configuration specification for the softswitch 106 from a softswitch specification repository included in therepositories 146 and/or downloaded from thecentral configuration controller 102. The configuration specification for thesoftswitch 106 may specify the configuration(s) of the VNF(s) and VM(s) implementing thesoftswitch 106, and/or any other configuration settings/data that define the implementation of thesoftswitch 106. In some examples, thenetwork node configurator 138 also accesses any real-time metrics, status, etc., from thesoftswitch 106. Thenetwork node configurator 138 uses the accessed configuration specification for thesoftswitch 106, and any other metrics, status, etc., to create/instantiate theduplicate softswitch 205 on thecompute node 104 such that theduplicate softswitch 205 is a digital copy (or digital twin) of thesoftswitch 106. - In some examples, the
network node configurator 138 uses the configuration specification for the softswitch 106 to create/instantiate theduplicate softswitch 205 on thecompute node 104 such that theduplicate softswitch 205 is an exact duplicate (e.g., a digital twin) of thesoftswitch 106. In other examples, thenetwork node configurator 138 uses the configuration specification for the softswitch 106 to create/instantiate theduplicate softswitch 205 on thecompute node 104 such that theduplicate softswitch 205 is substantially similar to thesoftswitch 106, except for some inconsequential differences in the configuration parameters. For example, the configuration specification for thesoftswitch 106 may specify configuration parameters defining the composition of thesoftswitch 106, such as a number of processing cores, an amount of memory, total number of data buffers (e.g., queues) for transmitting and receiving data packets, distribution of the data buffers (e.g., queues) across different data traffic classes (e.g., in terms of the number of data buffers assigned to each different data class), number of port connections assignable to VMs, etc. In examples in which theduplicate softswitch 205 is an exact duplicate (e.g., a digital twin) of thesoftswitch 106, thenetwork node configurator 138 may create/instantiate theduplicate softswitch 205 such that its configuration specification includes all of the same configuration parameters as the configuration specification of thesoftswitch 106. In examples in which theduplicate softswitch 205 is a substantially similar copy of thesoftswitch 106, thenetwork node configurator 138 may create/instantiate theduplicate softswitch 205 such that its configuration specification includes some of the same configuration parameters as the configuration specification of the softswitch 106 (e.g., such as the same number of processing cores, the same total number of data buffers (e.g., queues) for transmitting and receiving data packets, the same distribution of the data buffers (e.g., queues) across different data traffic classes, etc.), but other configuration parameters may differ (e.g., amount of memory, number of port connections assignable to VMs, etc.) if the parameters that differ will result in little to no change in operational performance between the softswitch 106 and the initially deployedduplicate softswitch 205. - In the illustrated example of
FIG. 2 , thenetwork node configurator 138 also connects theVNIC 144 of theVM 142, which has been deployed to thecompute node 104 to implement thevirtualized workload 140, to theduplicate softswitch 205. For example, thenetwork node configurator 138 may access a VM configuration file for theVM 142 from a VM configuration repository included in therepositories 146, access a configuration specification for the duplicate softswitch 205 (which initially corresponds/matches the configuration specification for softswitch 106) from the softswitch specification repository included in therepositories 146, and update the configuration files to map a port ofVNIC 144 of theVM 142 to a port of thesoftswitch 205. In the illustrated example, thenetwork node configurator 138 also configures theworkload 140 hosted by theVM 142 to operate in a test mode (e.g., by setting an appropriate configuration setting, value, field, etc.). - Turning to
FIG. 3 , after theduplicate softswitch 205 is instantiated on thecompute node 104 and connected to theVM 142, which is hosting theworkload 140 operating in test mode, thenetwork node configurator 138 deploys the updated TSN schedule to thesoftswitch 205 and tests the updated TSN schedule using simulated network traffic. For example, thenetwork node configurator 138 includes anexample traffic simulator 305, which implements an on-node simulation engine on thecompute node 104 that generates simulated network traffic to validate the updated TSN schedule implemented by theduplicate softswitch 205 before the validated updated TSN schedule is deployed for operation. Although thetraffic simulator 305 is illustrated as being implemented by thenetwork node configurator 138 in the illustrated example, in other examples, thetraffic simulator 305 could be a separate element implemented on thecompute node 104. Accordingly, thetraffic simulator 305 is an example means for applying simulated network traffic to a softswitch. - In some examples, the
traffic simulator 305 generates the simulated network traffic from actual network traffic monitored by thetraffic simulator 305 during operation of thesoftswitch 106. For example, thetraffic simulator 305 can monitor the actual network traffic communicated to/from the elements connected to thesoftswitch 106, such as theVMs 128/130 and thecontainer 132, during operation of theworkloads traffic simulator 305 stores the monitored network traffic in a simulated network traffic repository included in therepositories 146. For example, thetraffic simulator 305 can store the monitored network traffic as one or more packet-capture (PCAP) files in the simulated network traffic repository included in therepositories 146. In some examples, thetraffic simulator 305 also obtains a test traffic file, such as a test traffic PCAP file, associated withnew workload 140 being deployed to thecompute node 104. For example, theorchestrator 150 may transmit a test traffic file to the compute node 104 (e.g., to thenetwork node configurator 138 and/or the traffic simulator 305) with the VM configuration specification for theVM 142 implementing thenew workload 140, which is stored in the simulated network traffic repository included in therepositories 146. The test traffic file in such examples may be generated to mimic the network traffic to be transmitted to and/or received from the type of physical equipment expected to be in communication with theworkload 140. Additionally or alternatively, in some examples, the simulated network traffic repository included in therepositories 146 may store a library of different test traffic files for different types of workloads, and thetraffic simulator 305 may select a network traffic file for theworkload 140 from the repository based on the type of theworkload 140. - In the illustrated example, the
traffic simulator 305 generates the simulated network traffic to validate the updated TSN schedule by combining the previously monitored network traffic, which is associated with prior operation of thesoftswitch 106, with the test traffic file associated with thenew workload 140. Thetraffic simulator 305 then applies the simulated network traffic to theduplicate softswitch 205 by simulating appropriate virtual sources and sinks to send and receive the simulated network traffic processed by theduplicate softswitch 205. In the illustrated example, thetraffic simulator 305 also implements a virtual sink to receive network traffic sent by the workload 140 (and VM 142), which is operating in test mode, to process simulated network traffic received by theVM 142 and workload 140 (e.g., based on the test traffic file). Thenetwork node configurator 138 then monitors traffic performance metrics associated with the simulated network traffic processed by theduplicate softswitch 205 based on the updated TSN schedule. For example, one or more virtual network sinks implemented by thetraffic simulator 305 may be configured to receive the simulated network traffic traversing theduplicate softswitch 205 and generate traffic performance metrics (e.g., such as packet jitter, packet latency, etc.) from the simulated network traffic before discarding the simulated network packets. For example, the virtual sinks(s) may generate the traffic performance metrics for the simulated network traffic associated with (e.g., receive and/or transmitted) by the workload 140 (also referred to as the simulated traffic performance metrics for the workload 140). Additionally or alternatively, in some examples, the virtual sinks(s) may generate the traffic performance metrics for the respective simulated network traffic associated with (e.g., previously monitored for) one, or more, or all of theother workloads workloads network node configurator 138 and/ortraffic simulator 305 monitor switch metrics associated with operation of theduplicate softswitch 205 to process the simulated network traffic (e.g., such as buffer/queue utilization and/or overflow for different traffic classes specified by the updated TSN schedule, detected violations of the gate structure specified by the updated TSN schedule, etc.). The application of simulated network traffic to theduplicate softswitch 205, and the corresponding monitoring of the performance metrics, is represented by the directedline 310 in the example ofFIG. 3 . - In the illustrated example, the
network node configurator 138 monitors the traffic performance metrics and switch metrics, if available, associated with the simulated network traffic processed on theduplicate softswitch 205 based on the updated TSN schedule and compares the monitored performance metrics to one or more sets of constraints to validate the updated TSN schedule. For example, the constraints may correspond to one or more of the network communication scheduling requirements specified in theVIFD 158 for thenew workload 140 being deployed to thecompute node 104. In some such examples, thecentral user configurator 152 and/or thecentral network configurator 154 provide (e.g., with the deployment of the updated TSN schedule to the compute node 104) one or more sets of network performance constraints for thenew workload 140, which are parsed from theVIFD 158, to thenetwork node configurator 138. Thenetwork node configurator 138 can then store the one or more sets of network performance constraints for theworkload 140 in a workload scheduling and metrics specification repository included in therepositories 146. Likewise, the workload scheduling and metrics specification repository included in therepositories 146 may contain stored sets of network performance constraints previously received from thecentral user configurator 152 and/or thecentral network configurator 154 for theother workloads repositories 146 may also include targets for the switch metrics monitored by thenetwork node configurator 138. - In some examples, the network performance constraints obtained for the workload 140 (and previously for the
other workloads network node configurator 138 groups the network performance constraints to be evaluated into a first set of constraints including the identified first type of constraints (e.g., hard constraints) and a second set of constraints including the identified second type of constraints (e.g., soft constraints). In some such examples, if the simulated network traffic has monitored traffic metrics that meet the first set of constraints (e.g., hard constraints), thenetwork node configurator 138 may spend an amount of time up to a bounded time limit to adjust the configuration of theduplicate softswitch 205 to meet one or more of the constraints included in the second set of constraints (e.g., the soft constraints). In some examples, the bounded time limit, also referred to as an optimization time limit, is specified in theVIFD 158 for thenew workload 140 being deployed to thecompute node 104, and is provided to thenetwork node configurator 138 by thecentral user configurator 152 and/or thecentral network configurator 154 with the other constraints. In some such examples, the optimization time limit may be related to an amount of delay that can be tolerated while theworkload 140 is being deployed to thecompute node 104. - In the illustrated example, the
network node configurator 138 compares the simulated traffic performance metrics forworkload 140 and, in some examples, the simulated traffic performance metrics for theother workloads duplicate softswitch 205, with the respective sets of constraints for the corresponding workloads to determine whether the updated TSN schedule implemented by theduplicate softswitch 205 is valid. In some examples, thenetwork node configurator 138 may also compare the switch metrics determined for theduplicate softswitch 205 when processing the simulated network traffic to corresponding targets to determine whether the updated TSN schedule implemented by theduplicate softswitch 205 is valid. In some examples in which thenew workload 140 is associated with a first set of constraints corresponding to hard constraints and a second set of constraints corresponding to soft constraints, thenetwork node configurator 138 determines the updated TSN schedule is valid if the simulated traffic performance metrics associated with theworkload 140 satisfy the first set of constraints. In some such examples, if the existingworkloads network node configurator 138 determines the updated TSN schedule is valid if the simulated traffic performance metrics associated with therespective workloads - In some examples, after the
network node configurator 138 determines the updated TSN schedule is valid because the first sets of constraints corresponding to hard constraints are met, thenetwork node configurator 138 then determines whether the second set of constraints corresponding to soft constraints for theworkload 140. In some examples, thenetwork node configurator 138 also determines whether the respective second sets of constraints corresponding to soft constraints for theworkloads network node configurator 138 adjusts the configuration of theduplicate softswitch 205 to enable one or more of the soft constraints to be met. For example, theduplicate softswitch 205 may include multiple data buffers (e.g., queues) assigned to different data classes defined by the TSN schedule, which theduplicate softswitch 205 gates on and off to allow traffic to packets in the buffers to traverse thesoftswitch 205 to meet timing requirements specified by the updated TSN schedule. To adjust theduplicate softswitch 205 such that one or more of the soft constraints can be met, thenetwork node configurator 138 may adjust the number of data buffers (e.g., queues) assigned to the different data classes defined by the TSN schedule, adjust when and/or how often and/or for how long different ones of the data buffers (e.g., queues) are gated on to allow their respective packets to traverse thesoftswitch 205, etc. In some examples, thenetwork node configurator 138 adjusts theduplicate softswitch 205 iteratively such that ones of the soft constraints are met in priority weighting order, with higher soft constraints being optimized before lower soft constraints, resulting in iterative optimization of the soft constraints. In some examples, thenetwork node configurator 138 continues adjusting the configuration of theduplicate softswitch 205 iteratively until all soft constraints are met or until the bounded time limit for adjusting the configuration of theduplicate softswitch 205 is reached. At this point, the updated TSN schedule and configuration of theduplicate softswitch 205 are finalized and ready to be deployed on thecompute node 104 - Turning to
FIG. 4 , if thenetwork node configurator 138 determines the updated TSN schedule is not valid (e.g., because one or more of the first set of constraints corresponding to hard constraints, such as a frame delivery deadline, are not met by the updated TSN schedule), thenetwork node configurator 138 generates a failure message and sends the failure message to thecentral configuration controller 102 for receipt by thecentral user configurator 152 and theorchestrator 150. In response to the failure message, theorchestrator 150 causes the newvirtualized workload 140 instance to be deleted from the compute node 104 (e.g., by deleting its VM 142). Thenetwork node configurator 138 also deletes the updated TSN schedule and theduplicate softswitch 205 from thecompute node 104. - However, if the
network node configurator 138 determines the updated TSN schedule is valid (e.g., because the first set of constraints corresponding to hard constraints, such as a frame delivery deadline, are met by the updated TSN schedule), thenetwork node configurator 138 generates a success message and sends the success message to thecentral configuration controller 102 for receipt by thecentral user configurator 152 and theorchestrator 150. Thenetwork node configurator 138 is also responsible for replacing the existingsoftswitch 106 with thenew softswitch 205 and transitioning thenew workload 140 and the existingworkloads new softswitch 205. - For example, as shown in the example of
FIG. 4 , thenetwork node configurator 138 connects the newly configuredsoftswitch 205 implementing the updated TSN schedule to theNIC 122 of the compute node via the DPDK 126 (e.g., by updating the configuration specifications of therespective softswitches 106 and 205). Thenetwork node configurator 138 also adds new port connections to the respective VMs/containers workloads new softswitch 205, and deletes the previous port bindings associated with thesoftswitch 106, as shown (e.g., by updating the configuration files for the VMs/containers softswitches 106 and 205). Thenetwork node configurator 138 also configures thenew workload 140 hosted by theVM 142 to operate in an operational mode instead of test mode (e.g., by setting an appropriate configuration setting, value, field, etc.). Thenetwork node configurator 138 also stores the configuration specification for thenew softswitch 205 in the softswitch specification repository included in therepositories 146 and/or reports the configuration specification for thenew softswitch 205 to thecentral configuration controller 102. - Next, turning to
FIG. 5 , thenetwork node configurator 138 deletes theold softswitch 106 from thecompute node 104 and deletes its configuration specification from the softswitch specification repository included in therepositories 146. In this manner, thenetwork node configurator 138 replaces theold softswitch 106 implementing the old TSN schedule with thenew softswitch 205 implementing the updated TSN schedule. Because the switchover is performed after the updated TSN schedule implemented by thenew softswitch 205 is verified with the simulated network traffic, and can be accomplished quickly by updating configuration specification files for the VMs/containers softswitches workloads old softswitch 106 implementing the old TSN schedule to thenew softswitch 205 implementing the updated TSN schedule, thetraffic simulator 305 monitors the network traffic traversing the new softswitch 205 (e.g., which is associated with theworkloads repositories 146. This monitored network traffic stored in the simulated network traffic repository included in therepositories 146 can later be used, as described above, when another updated TSN schedule is to be deployed to thecompute node 104. - A block diagram of an example implementation of the
network node configurator 138 ofFIGS. 1-5 is illustrated inFIG. 7 . The examplenetwork node configurator 138 ofFIG. 7 includes anexample softswitch instantiator 705 to instantiate theduplicate softswitch 205 on thecompute node 104 in response to receiving the updated TSN schedule, as described above. Thenetwork node configurator 138 ofFIG. 7 includes an example TSN schedule configure 710 to configure theduplicate softswitch 205 to implement the updated TSN schedule, as described above. Thenetwork node configurator 138 ofFIG. 7 includes theexample traffic simulator 305 and an exampleTSN schedule validator 715 to validate the updated TSN schedule implemented by theduplicate softswitch 205, as described above. Thenetwork node configurator 138 ofFIG. 7 includes anexample softswitch replacer 720 to replace the existingsoftswitch 106 with thenew softswitch 205 on thecompute node 104 in response to successful validation of the updated TSN schedule, as described above. - While example manners of implementing the example
central configuration controller 102 and the examplenetwork node configurator 138 are illustrated inFIGS. 1-7 , one or more of the elements, processes and/or devices illustrated inFIGS. 1-7 may be combined, divided, re-arranged, omitted, eliminated and/or implemented in any other way. Further, theexample orchestrator 150, the examplecentral user configurator 152, the examplecentral network configurator 154, theexample scheduler 156, theexample traffic simulator 305, theexample softswitch instantiator 705, the example TSN schedule configure 710, the exampleTSN schedule validator 715, theexample softswitch replacer 720 and/or, more generally, the examplecentral configuration controller 102 and the examplenetwork node configurator 138 ofFIGS. 1-7 may be implemented by hardware, software, firmware and/or any combination of hardware, software and/or firmware. Thus, for example, any of theexample orchestrator 150, the examplecentral user configurator 152, the examplecentral network configurator 154, theexample scheduler 156, theexample traffic simulator 305, theexample softswitch instantiator 705, the example TSN schedule configure 710, the exampleTSN schedule validator 715, theexample softswitch replacer 720 and/or, more generally, the examplecentral configuration controller 102 and the examplenetwork node configurator 138 could be implemented by one or more analog or digital circuit(s), logic circuits, programmable processor(s), programmable controller(s), graphics processing unit(s) (GPU(s)), digital signal processor(s) (DSP(s)), application specific integrated circuit(s) (ASIC(s)), programmable logic device(s) (PLD(s)), field programmable gate arrays (FPGAs) and/or field programmable logic device(s) (FPLD(s)). When reading any of the apparatus or system claims of this patent to cover a purely software and/or firmware implementation, at least one of the examplecentral configuration controller 102, the examplenetwork node configurator 138, theexample orchestrator 150, the examplecentral user configurator 152, the examplecentral network configurator 154, theexample scheduler 156, theexample traffic simulator 305, theexample softswitch instantiator 705, the example TSN schedule configure 710, the exampleTSN schedule validator 715 and/or theexample softswitch replacer 720 is/are hereby expressly defined to include a non-transitory computer readable storage device or storage disk such as a memory, a digital versatile disk (DVD), a compact disk (CD), a Blu-ray disk, etc. including the software and/or firmware. Further still, the examplecentral configuration controller 102 and/or the examplenetwork node configurator 138 ofFIGS. 1-7 may include one or more elements, processes and/or devices in addition to, or instead of, those illustrated inFIGS. 1-7 , and/or may include more than one of any or all of the illustrated elements, processes and devices. As used herein, the phrase “in communication,” including variations thereof, encompasses direct communication and/or indirect communication through one or more intermediary components, and does not require direct physical (e.g., wired) communication and/or constant communication, but rather additionally includes selective communication at periodic intervals, scheduled intervals, aperiodic intervals, and/or one-time events. - Flowcharts and pseudocode representative of example hardware logic, machine readable instructions, hardware implemented state machines, and/or any combination thereof for implementing the example
central configuration controller 102 and the examplenetwork node configurator 138 are shown inFIGS. 8-14 . In these examples, the machine readable instructions may be one or more executable programs or portion(s) of an executable program for execution by a computer processor, such as theprocessor 1512 and/or 1612 shown in theexample processor platforms FIGS. 15-16 . The one or more programs, or portion(s) thereof, may be embodied in software stored on a non-transitory computer readable storage medium such as a CD-ROM, a floppy disk, a hard drive, a DVD, a Blu-ray Disk™, or a memory associated with theprocessors 1512 and/or 1612, but the entire program or programs and/or parts thereof could alternatively be executed by a device other than theprocessors 1512 and/or 1612, and/or embodied in firmware or dedicated hardware. Further, although the example program(s) is(are) described with reference to the flowcharts and pseudocode illustrated inFIGS. 8-14 , many other methods of implementing the examplecentral configuration controller 102 and/or the examplenetwork node configurator 138 may alternatively be used. For example, with reference to the flowcharts and pseudocode illustrated inFIGS. 8-14 , the order of execution of the blocks may be changed, and/or some of the blocks described may be changed, eliminated, combined and/or subdivided into multiple blocks. Additionally or alternatively, any or all of the blocks may be implemented by one or more hardware circuits (e.g., discrete and/or integrated analog and/or digital circuitry, an FPGA, an ASIC, a comparator, an operational-amplifier (op-amp), a logic circuit, etc.) structured to perform the corresponding operation without executing software or firmware. - The machine readable instructions described herein may be stored in one or more of a compressed format, an encrypted format, a fragmented format, a compiled format, an executable format, a packaged format, etc. Machine readable instructions as described herein may be stored as data (e.g., portions of instructions, code, representations of code, etc.) that may be utilized to create, manufacture, and/or produce machine executable instructions. For example, the machine readable instructions may be fragmented and stored on one or more storage devices and/or computing devices (e.g., servers). The machine readable instructions may require one or more of installation, modification, adaptation, updating, combining, supplementing, configuring, decryption, decompression, unpacking, distribution, reassignment, compilation, etc. in order to make them directly readable, interpretable, and/or executable by a computing device and/or other machine. For example, the machine readable instructions may be stored in multiple parts, which are individually compressed, encrypted, and stored on separate computing devices, wherein the parts when decrypted, decompressed, and combined form a set of executable instructions that implement a program such as that described herein.
- In another example, the machine readable instructions may be stored in a state in which they may be read by a computer, but require addition of a library (e.g., a dynamic link library (DLL)), a software development kit (SDK), an application programming interface (API), etc. in order to execute the instructions on a particular computing device or other device. In another example, the machine readable instructions may need to be configured (e.g., settings stored, data input, network addresses recorded, etc.) before the machine readable instructions and/or the corresponding program(s) can be executed in whole or in part. Thus, the disclosed machine readable instructions and/or corresponding program(s) are intended to encompass such machine readable instructions and/or program(s) regardless of the particular format or state of the machine readable instructions and/or program(s) when stored or otherwise at rest or in transit.
- The machine readable instructions described herein can be represented by any past, present, or future instruction language, scripting language, programming language, etc. For example, the machine readable instructions may be represented using any of the following languages: C, C++, Java, C #, Perl, Python, JavaScript, HyperText Markup Language (HTML), Structured Query Language (SQL), Swift, etc.
- As mentioned above, the example processes of
FIGS. 8-14 may be implemented using executable instructions (e.g., computer and/or machine readable instructions) stored on a non-transitory computer and/or machine readable medium such as a hard disk drive, a flash memory, a read-only memory, a compact disk, a digital versatile disk, a cache, a random-access memory and/or any other storage device or storage disk in which information is stored for any duration (e.g., for extended time periods, permanently, for brief instances, for temporarily buffering, and/or for caching of the information). As used herein, the term non-transitory computer readable medium is expressly defined to include any type of computer readable storage device and/or storage disk and to exclude propagating signals and to exclude transmission media. Also, as used herein, the terms “computer readable” and “machine readable” are considered equivalent unless indicated otherwise. - “Including” and “comprising” (and all forms and tenses thereof) are used herein to be open ended terms. Thus, whenever a claim employs any form of “include” or “comprise” (e.g., comprises, includes, comprising, including, having, etc.) as a preamble or within a claim recitation of any kind, it is to be understood that additional elements, terms, etc. may be present without falling outside the scope of the corresponding claim or recitation. As used herein, when the phrase “at least” is used as the transition term in, for example, a preamble of a claim, it is open-ended in the same manner as the term “comprising” and “including” are open ended. The term “and/or” when used, for example, in a form such as A, B, and/or C refers to any combination or subset of A, B, C such as (1) A alone, (2) B alone, (3) C alone, (4) A with B, (5) A with C, (6) B with C, and (7) A with B and with C. As used herein in the context of describing structures, components, items, objects and/or things, the phrase “at least one of A and B” is intended to refer to implementations including any of (1) at least one A, (2) at least one B, and (3) at least one A and at least one B. Similarly, as used herein in the context of describing structures, components, items, objects and/or things, the phrase “at least one of A or B” is intended to refer to implementations including any of (1) at least one A, (2) at least one B, and (3) at least one A and at least one B. As used herein in the context of describing the performance or execution of processes, instructions, actions, activities and/or steps, the phrase “at least one of A and B” is intended to refer to implementations including any of (1) at least one A, (2) at least one B, and (3) at least one A and at least one B. Similarly, as used herein in the context of describing the performance or execution of processes, instructions, actions, activities and/or steps, the phrase “at least one of A or B” is intended to refer to implementations including any of (1) at least one A, (2) at least one B, and (3) at least one A and at least one B.
- As used herein, singular references (e.g., “a”, “an”, “first”, “second”, etc.) do not exclude a plurality. The term “a” or “an” entity, as used herein, refers to one or more of that entity. The terms “a” (or “an”), “one or more”, and “at least one” can be used interchangeably herein. Furthermore, although individually listed, a plurality of means, elements or method actions may be implemented by, e.g., a single unit or processor. Additionally, although individual features may be included in different examples or claims, these may possibly be combined, and the inclusion in different examples or claims does not imply that a combination of features is not feasible and/or advantageous.
- An
example program 800 that may be executed to implement the examplecentral configuration controller 102 ofFIG. 1 is represented by the flowchart shown inFIG. 8 . With reference to the preceding figures and associated written descriptions, theexample program 800 begins execution atblock 805 at which thecentral configuration controller 102 accesses theVIFD 158 specifying thenew workload 140 to deploy to thecompute node 104. Atblock 810, theorchestrator 150 of thecentral configuration controller 102 parses theVIFD 158 to determine a VM configuration specification to implement theworkload 140, as described above. Atblock 815, thecentral user configurator 152 of thecentral configuration controller 102 parses the VIFD to determine a set of parameters for an updated TSN schedule to accommodate theworkload 140, as described above. Atblock 820, thecentral network configurator 154 of thecentral configuration controller 102 determines, as described above, the updated TSN schedule based on the set of parameters parsed from theVIFD 158 atblock 815. Atblock 825, theorchestrator 150 sends the VM configuration specification and a corresponding test traffic file to thecompute node 104 to deploy theworkload 140 at thecompute node 104, as described above. Atblock 830, thecentral network configurator 154 sends the updated TSN schedule to the compute node for deployment at thecompute node 104, as described above. - At
block 840, thecentral configuration controller 102 later receives a message, as described above, which indicates a deployment result for deploying theworkload 140 and the updated TSN schedule at thecompute node 104. If, atblock 840, thecentral configuration controller 102 determines the message indicates the updated TSN schedule was not deployable (e.g., was found to be invalid), processing proceeds to block 845; otherwise processing proceeds to block 850. Atblock 845, theorchestrator 150 deletes the VM configuration specification for theworkload 140 and thecentral network configurator 154 deletes the updated TSN schedule, as described above, which cancels the attempt to deploy theworkload 140 and the updated TSN schedule to thecompute node 104. Atblock 850, theorchestrator 150 retains the VM configuration specification for theworkload 140 and thecentral network configurator 154 retains the updated TSN schedule, as described above, which tracks the successful deployment of theworkload 140 and the updated TSN schedule to thecompute node 104. - An
example program 900 that may be executed to implement the examplenetwork node configurator 138 ofFIGS. 1-5 and/or 7 is represented by the flowchart shown inFIG. 9 . With reference to the preceding figures and associated written descriptions, theexample program 900 begins execution atblock 905 at which thenetwork node configurator 138 accesses a VM configuration specification and associated test traffic file received from thecentral configuration controller 102 for thenew workload 140 to be deployed at thecompute node 104, as described above. Atblock 910, thenetwork node configurator 138 accesses an updated TSN schedule received from thecentral configuration controller 102 for implementation by thesoftswitch 106 on thecompute node 104, as described above. Atblock 915, thesoftswitch instantiator 705 of thenetwork node configurator 138 deploys theduplicate softswitch 205 on thecompute node 104 based on (e.g., to match) a first configuration of thesoftswitch 106 executing on thecompute node 104, as described above. Atblock 920, the TSN schedule configure 710 of thenetwork node configurator 138 configures theduplicate softswitch 205 to implement the updated TSN schedule, as described above. Atblock 925, theTSN schedule validator 715 of thenetwork node configurator 138 determines whether a first set of constraints (e.g., hard constraints) is met for simulated network traffic processed by theduplicate softswitch 205 based on the updated TSN schedule, as described above. Anexample program 925P that may be executed to implement the processing atblock 925 is illustrated inFIG. 10 , which is described below. - If the first set of constraints (e.g., hard constraints) are met, processing proceeds to block 935; otherwise processing proceeds to block 940. At
block 940, thenetwork node configurator 138 determines the updated TSN schedule is invalid and, thus, deletes theduplicate softswitch 205 and theVM 142 that was deployed to implement theworkload 140, as described above. At block 945, thenetwork node configurator 138 reports a deployment failure status message to thecentral configuration controller 102, as described above. - Conversely, at
block 935, thenetwork node configurator 138 determines the updated TSN schedule is valid and, thus, adjusts the second configuration associated with theduplicate softswitch 205 to satisfy one or more of a second set of constraints (e.g., soft constraints) to be met for the simulated network traffic processed by theduplicate softswitch 205 based on the updated TSN schedule, as described above. At block, thesoftswitch replacer 720 of thenetwork node configurator 138 replaces the existingsoftswitch 106 with thenew softswitch 205, as describe above. Anexample program 950P that may be executed to implement the processing atblock 950 is illustrated inFIG. 12 , which is described below. Atblock 955, thenetwork node configurator 138 reports a deployment success status message to thecentral configuration controller 102, as described above. - An
example program 925P that may be executed to implement the processing atblock 925 ofFIG. 9 is illustrated inFIG. 10 . With reference to the preceding figures and associated written descriptions, theexample program 925P begins execution atblock 1005 at which the exampleTSN schedule validator 715 of thenetwork node configurator 138 connects a port of theVM 142, which is being deployed to implement theworkload 140, to theduplicate softswitch 205, as described above. Atblock 1010, theTSN schedule validator 715 configures theworkload 140 hosted by theVM 142 to operate in test mode, as described above. Atblock 1015, theTSN schedule validator 715 invokes thetraffic simulator 305 to apply simulated network traffic to theduplicate softswitch 205, as described above. Atblock 1020, theTSN schedule validator 715 monitors metrics associated with the simulate network traffic processed by thesoftswitch 205 based on the updated TSN schedule, as described above. Atblock 1025, theTSN schedule validator 715 compares the monitored metrics to the first set of constraints (e.g., hard constraints), as described above.Example pseudocode 1025S that may be executed to implement the processing atblock 1025 is illustrated inFIG. 11 . - An
example program 950P that may be executed to implement the processing atblock 950 ofFIG. 9 is illustrated inFIG. 12 . With reference to the preceding figures and associated written descriptions, theexample program 950P begins execution atblock 1205 at which thesoftswitch replacer 720 of thenetwork node configurator 138 connects thenew softswitch 205 to theNIC 122 of thecompute node 104, as described above. Atblock 1210, thesoftswitch replacer 720 adds respective new port connections to the corresponding existing VMs/containers workloads compute node 104, as described above. Atblock 1215, thesoftswitch replacer 720 binds the new port connections of the VMs/containers new softswitch 205, as described above. Atblock 1220, thesoftswitch replacer 720 deletes the prior port connections of the VMs/containers softswitch 106, as described above. Atblock 1225, thesoftswitch replacer 720 sets thenew workload 140 hosted by thenew VM 142, which is already connected to thenew softswitch 205, to operational mode, as described above. Atblock 1230, thesoftswitch replacer 720 deletes the softswitch 106 from thecompute node 104, as described above. Atblock 1235, thesoftswitch replacer 720 invokes thetraffic simulator 305 to monitor the network traffic processed by thenew softswitch 205 based on the updated TSN schedule to generate new simulated network traffic to be used to validate future TSN schedule updates, as described above. - An
example program 1300 that may be executed to implement the examplecentral configuration controller 102 and the examplenetwork node configurator 138 is represented by the flowchart shown inFIGS. 13-14 . With reference to the preceding figures and associated written descriptions, theexample program 1300 begins execution atblock 1302 at which thecentral user configurator 152 of thecentral configuration controller 102 accesses and parses theVIFD 158 for theworkload 140 corresponding to a new service deployment to obtain the network scheduling requirements for theworkload 140, as described above. Atblock 1304, thecentral network configurator 154 determines an updated TSN schedule based on the network scheduling requirements parsed from theVIFD 158, as described. Atblock 1306, thenetwork node configurator 138 receives from thecentral network configurator 154 the updated TSN schedule and set(s) of constraints to be evaluated to validate the updated TSN schedule on thecompute node 104, as described above. In parallel, atblock 1308, theorchestrator 150 of thecentral configuration controller 102 parses theVIFD 158 for theworkload 140 to determine the workload deployment requirements to be used to create the VM 142 (or container) to be deployed to implement thenew workload 140, as described above. Processing then proceeds to anexample subroutine 1310, which is illustrated inFIG. 14 . - The
subroutine 1310 ofFIG. 14 begins execution atblock 1312 at which theorchestrator 150 deploys theVM 142 on thecompute node 104 to implement theworkload 140 at thecompute node 104. Atblock 1314, theorchestrator 150 sends a test traffic file for theworkload 140 to thenetwork node configurator 138, as described above. Atblock 1316, thenetwork node configurator 138 receives, from thecentral network configurator 154, the updated TSN schedule and the set(s) of constraints parsed fromVIFD 158, and initiates deployment of the duplicate softswitch 206, as described above. Atblock 1318, thecentral network configurator 154 deploys, as described above, the duplicate softswitch 206 based on (e.g., to match) the configuration specification obtained for the existingsoftswitch 106 from the softswitch specification repository included in the repositories 146 (represented byblock 1320 inFIG. 14 ). - At
block 1322, thenetwork node configurator 138 connects theVM 142 implementing thenew workload 140 to theduplicate softswitch 205 and sets theworkload 140 hosted by theVM 142 to test mode, as described above. Atblock 1324, thenetwork node configurator 138 invokes thetraffic simulator 305 to apply simulated network traffic to theduplicate softswitch 205 to validate the updated TSN schedule, as described above. As described above, the simulated network traffic is obtained from the simulated network traffic repository included in the repositories 146 (represented byblock 1326 inFIG. 14 ). As described above, the simulated network traffic is collected by one or more virtual network sinks which determine traffic performance metrics associated with the simulated network traffic processed by theduplicate softswitch 205 based on the updated TSN schedule (block 1328). Atblock 1330, thenetwork node configurator 138 also monitors switch metrics associated with processing of the simulated network traffic by theduplicate softswitch 205, as described above. When the simulated network traffic is complete (block 1332), processing proceeds to block 1334. - At
block 1334, thenetwork node configurator 138 compares, as described above, the monitored metrics with the first set of constraints (e.g., hard constraints) obtained from the workload scheduling and metrics specification repository included in the repositories 146 (represented byblock 1336 inFIG. 14 ). Atblock 1338, thenetwork node configurator 138 determines, as described above, whether the first set of constraints (e.g., hard constraints) is met and, thus, whether the updated TSN schedule is valid. If the updated TSN schedule is not valid because one or of the first set of constraints was not met (block 1338), then processing returns from the subroutine 1332 (represented byblock 1340 inFIG. 14 ). However, if the updated TSN schedule is valid (block 1338), then atblock 1342, thenetwork node configurator 138 adjusts the configuration of thenew softswitch 205 to cause one or more of the second set of constraints (e.g., soft constraints) obtained from the workload scheduling and metrics specification repository to be met. Atblock 1344, thenetwork node configurator 138 continues to iteratively adjust perform such constraint optimization until the second set of constraints (e.g., soft constraints) is met or the bounded time limit is met, as described above. Processing then returns from the subroutine 1332 (represented byblock 1340 inFIG. 14 ). - Returning to
FIG. 13 , atblock 1346, thenetwork node configurator 138 causes processing to proceed to block 1348 if the updated TSN schedule is determined not to be valid, and causes processing to proceed to block 1350 if the updated TSN schedule is determined to be valid. Atblock 1348, thenetwork node configurator 138 generates a deployment failure message and transmits the failure message to thecentral configuration controller 102, as described above. Atblock 1352, theorchestrator 150 and thecentral user configurator 152 receive the deployment failure message. Atblock 1354, theorchestrator 150 and thecentral user configurator 152 deletes theVM 142 implementing theworkload 140 and the updated TSN schedule, as described above. - Conversely, at
block 1350, thenetwork node configurator 138 adds respective new port connections to the corresponding existing VMs/containers workloads compute node 104, binds the new port connections of the VMs/containers new softswitch 205, and deletes the prior port connections of the VMs/containers softswitch 106, as described above. Atblock 1358, thenetwork node configurator 138 deletes the softswitch 106 from thecompute node 104, as described above, and deletes the configuration specification for the softswitch 106 from the softswitch specification repository included in the repositories 146 (represented byblock 1360 ofFIG. 13 .) Atblock 1362, thenetwork node configurator 138 invokes thetraffic simulator 305 to monitor, as described above, the network traffic processed by thenew softswitch 205 based on the updated TSN schedule to generate new simulated network traffic to store in the simulated network traffic repository included in the repositories 146 (represented byblock 1364 ofFIG. 13 ). -
FIG. 15 is a block diagram of anexample processor platform 1500 structured to execute the instructions ofFIGS. 8, 13 and/or 14 to implement the example central configuration controller ofFIG. 1 . Theprocessor platform 1500 can be, for example, a server, a personal computer, a workstation, a self-learning machine (e.g., a neural network), a mobile device (e.g., a cell phone, a smart phone, a tablet such as an iPad′) or any other type of computing device. - The
processor platform 1500 of the illustrated example includes aprocessor 1512. Theprocessor 1512 of the illustrated example is hardware. For example, theprocessor 1512 can be implemented by one or more integrated circuits, logic circuits, microprocessors, GPUs, DSPs, or controllers from any desired family or manufacturer. Thehardware processor 1512 may be a semiconductor based (e.g., silicon based) device. In this example, theprocessor 1512 implements theorchestrator 150, thecentral user configurator 152, thecentral network configurator 154 and thescheduler 156. - The
processor 1512 of the illustrated example includes a local memory 1513 (e.g., a cache). Theprocessor 1512 of the illustrated example is in communication with a main memory including avolatile memory 1514 and anon-volatile memory 1516 via alink 1518. Thelink 1518 may be implemented by a bus, one or more point-to-point connections, etc., or a combination thereof. Thevolatile memory 1514 may be implemented by Synchronous Dynamic Random Access Memory (SDRAM), Dynamic Random Access Memory (DRAM), RAMBUS® Dynamic Random Access Memory (RDRAM®) and/or any other type of random access memory device. Thenon-volatile memory 1516 may be implemented by flash memory and/or any other desired type of memory device. Access to themain memory - The
processor platform 1500 of the illustrated example also includes aninterface circuit 1520. Theinterface circuit 1520 may be implemented by any type of interface standard, such as an Ethernet interface, a universal serial bus (USB), a Bluetooth® interface, a near field communication (NFC) interface, and/or a PCI express interface. - In the illustrated example, one or
more input devices 1522 are connected to theinterface circuit 1520. The input device(s) 1522 permit(s) a user to enter data and/or commands into theprocessor 1512. The input device(s) can be implemented by, for example, an audio sensor, a microphone, a camera (still or video), a keyboard, a button, a mouse, a touchscreen, a track-pad, a trackball, a trackbar (such as an isopoint), a voice recognition system and/or any other human-machine interface. Also, many systems, such as theprocessor platform 1500, can allow the user to control the computer system and provide data to the computer using physical gestures, such as, but not limited to, hand or body movements, facial expressions, and face recognition. - One or
more output devices 1524 are also connected to theinterface circuit 1520 of the illustrated example. Theoutput devices 1524 can be implemented, for example, by display devices (e.g., a light emitting diode (LED), an organic light emitting diode (OLED), a liquid crystal display (LCD), a cathode ray tube display (CRT), an in-place switching (IPS) display, a touchscreen, etc.), a tactile output device, a printer and/or speakers(s). Theinterface circuit 1520 of the illustrated example, thus, typically includes a graphics driver card, a graphics driver chip and/or a graphics driver processor. - The
interface circuit 1520 of the illustrated example also includes a communication device such as a transmitter, a receiver, a transceiver, a modem, a residential gateway, a wireless access point, and/or a network interface to facilitate exchange of data with external machines (e.g., computing devices of any kind) via anetwork 1526, such as the network 145. The communication can be via, for example, an Ethernet connection, a digital subscriber line (DSL) connection, a telephone line connection, a coaxial cable system, a satellite system, a line-of-site wireless system, a cellular telephone system, etc. - The
processor platform 1500 of the illustrated example also includes one or moremass storage devices 1528 for storing software and/or data. Examples of suchmass storage devices 1528 include floppy disk drives, hard drive disks, compact disk drives, Blu-ray disk drives, redundant array of independent disks (RAID) systems, and digital versatile disk (DVD) drives. In some examples, thevolatile memory 1514 and/or themass storage device 1528 may store the VIFDs processed by thecentral configuration controller 102. - The machine
executable instructions 1532 corresponding to the instructions ofFIGS. 8, 13 and/or 14 may be stored in themass storage device 1528, in thevolatile memory 1514, in thenon-volatile memory 1516, in thelocal memory 1513 and/or on a removable non-transitory computer readable storage medium, such as a CD orDVD 1536. -
FIG. 16 is a block diagram of anexample processor platform 1600 structured to execute the instructions ofFIGS. 9, 10, 11, 12, 13 and/or 14 to implement the examplenetwork node configurator 138 ofFIGS. 1-5 and/or 7 . Theprocessor platform 1600 can be, for example, a server, a personal computer, a workstation, a self-learning machine (e.g., a neural network), a mobile device (e.g., a cell phone, a smart phone, a tablet such as an iPad™) or any other type of computing device. - The
processor platform 1600 of the illustrated example includes aprocessor 1612. Theprocessor 1612 of the illustrated example is hardware. For example, theprocessor 1612 can be implemented by one or more integrated circuits, logic circuits, microprocessors, GPUs, DSPs, or controllers from any desired family or manufacturer. Thehardware processor 1612 may be a semiconductor based (e.g., silicon based) device. In this example, theprocessor 1612 implements thetraffic simulator 305, thesoftswitch instantiator 705, the TSN schedule configure 710, theTSN schedule validator 715 and thesoftswitch replacer 720. - The
processor 1612 of the illustrated example includes a local memory 1613 (e.g., a cache). Theprocessor 1612 of the illustrated example is in communication with a main memory including avolatile memory 1614 and anon-volatile memory 1616 via alink 1618. Thelink 1618 may be implemented by a bus, one or more point-to-point connections, etc., or a combination thereof. Thevolatile memory 1614 may be implemented by SDRAM, DRAM, RDRAM® and/or any other type of random access memory device. Thenon-volatile memory 1616 may be implemented by flash memory and/or any other desired type of memory device. Access to themain memory - The
processor platform 1600 of the illustrated example also includes aninterface circuit 1620. Theinterface circuit 1620 may be implemented by any type of interface standard, such as an Ethernet interface, a USB, a Bluetooth® interface, an NFC interface, and/or a PCI express interface. - In the illustrated example, one or
more input devices 1622 are connected to theinterface circuit 1620. The input device(s) 1622 permit(s) a user to enter data and/or commands into theprocessor 1612. The input device(s) can be implemented by, for example, an audio sensor, a microphone, a camera (still or video), a keyboard, a button, a mouse, a touchscreen, a track-pad, a trackball, a trackbar (such as an isopoint), a voice recognition system and/or any other human-machine interface. Also, many systems, such as theprocessor platform 1600, can allow the user to control the computer system and provide data to the computer using physical gestures, such as, but not limited to, hand or body movements, facial expressions, and face recognition. - One or
more output devices 1624 are also connected to theinterface circuit 1620 of the illustrated example. Theoutput devices 1624 can be implemented, for example, by display devices (e.g., an LED, an OLED, an LCD, a CRT display, an IPS display, a touchscreen, etc.), a tactile output device, a printer and/or speakers(s). Theinterface circuit 1620 of the illustrated example, thus, typically includes a graphics driver card, a graphics driver chip and/or a graphics driver processor. - The
interface circuit 1620 of the illustrated example also includes a communication device such as a transmitter, a receiver, a transceiver, a modem, a residential gateway, a wireless access point, and/or a network interface to facilitate exchange of data with external machines (e.g., computing devices of any kind) via anetwork 1626, such as the network 145. The communication can be via, for example, an Ethernet connection, a DSL connection, a telephone line connection, a coaxial cable system, a satellite system, a line-of-site wireless system, a cellular telephone system, etc. - The
processor platform 1600 of the illustrated example also includes one or moremass storage devices 1628 for storing software and/or data. Examples of suchmass storage devices 1628 include floppy disk drives, hard drive disks, compact disk drives, Blu-ray disk drives, RAID systems, and DVD drives. In some examples, thevolatile memory 1614 and/or themass storage device 1628 may implement one or more of therepositories 146. - The machine
executable instructions 1632 corresponding to the instructions ofFIGS. 9, 10, 11, 12, 13 and/or 14 may be stored in themass storage device 1628, in thevolatile memory 1614, in thenon-volatile memory 1616, in thelocal memory 1613 and/or on a removable non-transitory computer readable storage medium, such as a CD orDVD 1636. - From the foregoing, it will be appreciated that example methods, apparatus and articles of manufacture have been disclosed that change a TSN schedule implemented by a softswitch on a compute node operating in a time sensitive network. Disclosed example methods, apparatus and articles of manufacture improve the efficiency of the compute node by using a duplicate softswitch, also referred to herein as a digital twin softswitch, to enable dynamic changing of the existing TSN schedule implemented by the softswitch executing on the compute node, which may be caused by a new workload being deployed in the time sensitive network, without impacting the deterministic and real-time packet communications associated with existing workloads connected to the softswitch. Disclosed example methods, apparatus and articles of manufacture also utilize the duplicate softswitch (digital twin softswitch) to validate an updated TSN schedule in situ with a new workload being deployed, and can prevent deployment of the updated TSN schedule if a performance issue is detected. Disclosed methods, apparatus and articles of manufacture are accordingly directed to one or more improvement(s) in the functioning of a computer.
- The foregoing disclosure provides example solutions to change a time sensitive networking schedule implemented by a softswitch. The following further examples, which include subject matter such as at least one softswitch time sensitive networking schedule changing apparatus, at least one non-transitory computer readable medium including instructions that, when executed, cause at least one processor to change a time sensitive networking schedule implemented by a softswitch, and a softswitch time sensitive networking schedule changing method, are disclosed herein. Disclosed examples can be implemented individually and/or in one or more combinations.
- Example 1 is an apparatus to change a time sensitive networking schedule implemented by a first softswitch on a compute node. The apparatus of example 1 includes a network node configurator and a traffic simulator. The network node configurator of example 1 is to (i) deploy a second softswitch on the compute node based on a first configuration specification associated with the first softswitch, (ii) configure the second softswitch to implement an updated time sensitive networking schedule different from the time sensitive networking schedule implemented by the first softswitch, and (iii) replace the first softswitch with the second softswitch in response to a determination that a first set of constraints is met for simulated network traffic processed by the second softswitch based on the updated time sensitive networking schedule. The traffic simulator of example 1 is to apply the simulated network traffic to the second softswitch.
- Example 2 includes the subject matter of example 1, wherein the first softswitch is to communicate with respective first ports of corresponding ones of a first set of virtual machines on the compute node to provide the first set of virtual machines with access to a network that implements time sensitive networking, and to replace the first softswitch with the second softswitch, the network node configurator is to: (i) connect the second softswitch to a network interface of the compute node; (ii) add respective second ports to corresponding ones of the first set of virtual machines; (iii) bind the respective second ports of the corresponding ones of the first set of virtual machines to the second softswitch; (iv) delete the respective first ports of the corresponding ones of the first set of virtual machines; and (v) delete the first softswitch from the compute node.
- Example 3 includes the subject matter of example 1 or example 2, wherein the updated time sensitive networking schedule is to support deployment of a new virtual machine to the compute node to host a workload, and the network node configurator is to: (i) connect a port of the new virtual machine to the second softswitch; (ii) configure the workload to operate in a test mode; (iii) monitor a metric associated with the simulated network traffic processed by the second softswitch; and (iv) configure the workload to operate in an operational mode after the determination that the first set of constraints is met for the simulated network traffic processed by the second softswitch based on the updated time sensitive networking schedule.
- Example 4 includes the subject matter of example 3, wherein the simulated network traffic includes: (i) first simulated network traffic associated with a first set of virtual machines on the compute node, the first set of virtual machines in communication with the first softswitch, the first simulated traffic corresponding to previously monitored network traffic obtained during operation of the first set of virtual machines; and (ii) second simulated network traffic associated with the new virtual machine.
- Example 5 includes the subject matter of any one of examples 1 to 4, wherein the network node configurator is to delete the second softswitch and the updated time sensitive networking schedule from the compute node in response to a determination that the first set of constraints is not met for the simulated network traffic processed by the second softswitch based on the updated time sensitive networking schedule.
- Example 6 includes the subject matter of any one of examples 1 to 5, wherein the second softswitch is associated with a second configuration specification, the second configuration specification to correspond to the first configuration specification when the second softswitch is initially deployed on the compute node, and in response to the determination that the first set of constraints is met for the simulated network traffic, the network node configurator is to adjust the second configuration of the second softswitch to satisfy at least one of a second set of constraints to be met for the simulated network traffic processed by the second softswitch based on the updated time sensitive networking schedule.
- Example 7 includes the subject matter of example 6, wherein the network node configurator is to iteratively adjust the second configuration of the second softswitch to satisfy other ones of the second set of constraints to be met for the simulated network traffic until a time limit is reached.
- Example 8 is at least one non-transitory computer readable medium comprising computer readable instructions which, when executed, cause at least one processor to at least: (i) deploy a second softswitch on a compute node based on a first configuration specification associated with a first softswitch on the compute node; (ii) configure the second softswitch to implement a second time sensitive networking schedule different from a first time sensitive networking schedule implemented by the first softswitch; and (iii) replace the first softswitch with the second softswitch in response to a determination that a first set of constraints is met for simulated network traffic processed by the second softswitch based on the second time sensitive networking schedule.
- Example 9 includes the subject matter of example 8, wherein the first softswitch is to communicate with respective first ports of corresponding ones of a first set of virtual machines on the compute node to provide the first set of virtual machines with access to a network that implements time sensitive networking, and to replace the first softswitch with the second softswitch, the instructions, when executed, cause the at least one processor to: (i) connect the second softswitch to a network interface of the compute node; (ii) add respective second ports to corresponding ones of the first set of virtual machines; (iii) bind the respective second ports of the corresponding ones of the first set of virtual machines to the second softswitch; (iv) delete the respective first ports of the corresponding ones of the first set of virtual machines; and (v) delete the first softswitch from the compute node.
- Example 10 includes the subject matter of example 8 or example 9, wherein the second time sensitive networking schedule is to support deployment of a new virtual machine to the compute node to host a workload, and the instructions, when executed, cause the at least one processor to: (i) connect a port of the new virtual machine to the second softswitch; (ii) configure the workload to operate in a test mode; (iii) monitor a metric associated with the simulated network traffic processed by the second softswitch; and (iv) configure the workload to operate in an operational mode after the determination that the first set of constraints is met for the simulated network traffic processed by the second softswitch based on the second time sensitive networking schedule.
- Example 11 includes the subject matter of example 10, wherein the simulated network traffic includes: (i) first simulated network traffic associated with a first set of virtual machines on the compute node, the first set of virtual machines in communication with the first softswitch, the first simulated traffic corresponding to previously monitored network traffic obtained during operation of the first set of virtual machines; and (ii) second simulated network traffic associated with the new virtual machine.
- Example 12 includes the subject matter of any one of examples 8 to 11, wherein the instructions, when executed, cause the at least one processor to delete the second softswitch and the second time sensitive networking schedule from the compute node in response to a determination that the first set of constraints is not met for the simulated network traffic processed by the second softswitch based on the second time sensitive networking schedule.
- Example 13 includes the subject matter of any one of examples 8 to 12, wherein the second softswitch is associated with a second configuration specification, the second configuration specification to correspond to the first configuration specification when the second softswitch is initially deployed on the compute node, and in response to the determination that the first set of constraints is met for the simulated network traffic, the instructions, when executed, cause the at least one processor to adjust the second configuration of the second softswitch to satisfy at least one of a second set of constraints to be met for the simulated network traffic processed by the second softswitch based on the second time sensitive networking schedule.
- Example 14 includes the subject matter of example 13, wherein the instructions, when executed, cause the at least one processor to iteratively adjust the second configuration of the second softswitch to satisfy other ones of the second set of constraints to be met for the simulated network traffic until a time limit is reached.
- Example 15 is a method to change a time sensitive networking schedule implemented by a first softswitch on a compute node. The method of
claim 15 includes deploying a second softswitch on the compute node based on a first configuration specification associated with the first softswitch. The method ofclaim 15 also includes configuring the second softswitch to implement an updated time sensitive networking schedule different from the time sensitive networking schedule implemented by the first softswitch. The method ofclaim 15 further includes replacing the first softswitch with the second softswitch in response to a determination that a first set of constraints is met for simulated network traffic processed by the second softswitch based on the updated time sensitive networking schedule. - Example 16 includes the subject matter of example 15, wherein the first softswitch is to communicate with respective first ports of corresponding ones of a first set of virtual machines on the compute node to provide the first set of virtual machines with access to a network that implements time sensitive networking, and replacing the first softswitch with the second softswitch includes: (i) connecting the second softswitch to a network interface of the compute node; (ii) adding respective second ports to corresponding ones of the first set of virtual machines; (iii) binding the respective second ports of the corresponding ones of the first set of virtual machines to the second softswitch; (iv) deleting the respective first ports of the corresponding ones of the first set of virtual machines; and (v) deleting the first softswitch from the compute node.
- Example 17 includes the subject matter of example 15 or example 16, wherein the updated time sensitive networking schedule is to support deployment of a new virtual machine to the compute node to host a workload, and further including: (i) connecting a port of the new virtual machine to the second softswitch; (ii) configuring the workload to operate in a test mode; (iii) monitoring a metric associated with the simulated network traffic processed by the second softswitch; and (iv) configuring the workload to operate in an operational mode after the determination that the first set of constraints is met for the simulated network traffic processed by the second softswitch based on the updated time sensitive networking schedule.
- Example 18 includes the subject matter of example 17, wherein the simulated network traffic includes: (i) first simulated network traffic associated with a first set of virtual machines on the compute node, the first set of virtual machines in communication with the first softswitch, the first simulated traffic corresponding to previously monitored network traffic obtained during operation of the first set of virtual machines; and (ii) second simulated network traffic associated with the new virtual machine.
- Example 19 includes the subject matter of any one of examples 15 to 18, and further includes deleting the second softswitch and the updated time sensitive networking schedule from the compute node in response to a determination that the first set of constraints is not met for the simulated network traffic processed by the second softswitch based on the updated time sensitive networking schedule.
- Example 20 includes the subject matter of any one of examples 15 to 19, wherein the second softswitch is associated with a second configuration specification, the second configuration specification to correspond to the first configuration specification when the second softswitch is initially deployed on the compute node, and in response to the determination that the first set of constraints is met for the simulated network traffic, further including adjusting the second configuration of the second softswitch to satisfy at least one of a second set of constraints to be met for the simulated network traffic processed by the second softswitch based on the updated time sensitive networking schedule.
- Example 21 includes the subject matter of example 20, and further includes iteratively adjusting the second configuration of the second softswitch to satisfy other ones of the second set of constraints to be met for the simulated network traffic until a time limit is reached.
- Example 22 is an apparatus including means for replacing a first softswitch implementing a first time sensitive networking schedule on a compute node with a second softswitch implementing a second time sensitive networking schedule different from the first time sensitive networking schedule, the means for replacing to: (i) deploy the second softswitch on the compute node based on a first configuration specification associated with the first softswitch; (ii) configure the second softswitch to implement the second time sensitive networking schedule; and (iii) replace the first softswitch with the second softswitch in response to a determination that a first set of constraints is met for simulated network traffic processed by the second softswitch based on the second time sensitive networking schedule. The apparatus of example 22 also includes means for applying the simulated network traffic to the second softswitch.
- Example 23 includes the subject matter of example 22, wherein the first softswitch is to communicate with respective first ports of corresponding ones of a first set of virtual machines on the compute node to provide the first set of virtual machines with access to a network that implements time sensitive networking, and the means for replacing is to: (i) connect the second softswitch to a network interface of the compute node; (ii) add respective second ports to corresponding ones of the first set of virtual machines; (iii) bind the respective second ports of the corresponding ones of the first set of virtual machines to the second softswitch; (iv) delete the respective first ports of the corresponding ones of the first set of virtual machines; and (v) delete the first softswitch from the compute node.
- Example 24 includes the subject matter of example 22 or example 23, wherein the second time sensitive networking schedule is to support deployment of a new virtual machine to the compute node to host a workload, and the means for replacing is to: (i) connect a port of the new virtual machine to the second softswitch; (ii) configure the workload to operate in a test mode; (iii) monitor a metric associated with the simulated network traffic processed by the second softswitch; and (iv) configure the workload to operate in an operational mode after the determination that the first set of constraints is met for the simulated network traffic processed by the second softswitch based on the second time sensitive networking schedule.
- Example 25 includes the subject matter of example 24, wherein the simulated network traffic includes: (i) first simulated network traffic associated with a first set of virtual machines on the compute node, the first set of virtual machines in communication with the first softswitch, the first simulated traffic corresponding to previously monitored network traffic obtained during operation of the first set of virtual machines; and (ii) second simulated network traffic associated with the new virtual machine.
- Example 26 includes the subject matter of any one of examples 22 to 25, wherein the means for replacing is to delete the second softswitch and the second time sensitive networking schedule from the compute node in response to a determination that the first set of constraints is not met for the simulated network traffic processed by the second softswitch based on the second time sensitive networking schedule.
- Example 27 includes the subject matter of any one of examples 22 to 26, wherein the second softswitch is associated with a second configuration specification, the second configuration specification to correspond to the first configuration specification when the second softswitch is initially deployed on the compute node, and in response to the determination that the first set of constraints is met for the simulated network traffic, the means for replacing is to adjust the second configuration of the second softswitch to satisfy at least one of a second set of constraints to be met for the simulated network traffic processed by the second softswitch based on the second time sensitive networking schedule.
- Example 28 includes the subject matter of example 27, wherein the means for replacing is to iteratively adjust the second configuration of the second softswitch to satisfy other ones of the second set of constraints to be met for the simulated network traffic until a time limit is reached.
- Example 29 is an apparatus to change a time sensitive networking schedule implemented by a softswitch on a compute node. The apparatus of example 29 includes a central user configurator to parse a virtualized industrial function descriptor corresponding to a virtualized workload to determine a set of parameters for an updated time sensitive networking schedule to be implemented by the softswitch. The apparatus of example 29 also includes a central network configurator to: (i) determine the updated time sensitive networking schedule based on the set of parameters; and (ii) send the updated time sensitive networking schedule to the compute node.
- Example 30 includes the subject matter of example 29, and further includes an orchestrator to parse the virtualized industrial function descriptor to determine a virtual machine configuration specification for a virtual machine to deploy on the compute node to host the virtualized workload, and to send the virtual machine configuration specification to the compute node to cause the virtual machine to be deployed on the compute node.
- Example 31 includes the subject matter of example 30, wherein the orchestrator is to delete the virtual machine from the compute node in response to a message from the compute node indicating a first set of constraints is not met by the updated time sensitive networking schedule.
- Example 32 includes the subject matter of any one of examples 29 to 31, wherein the central user configurator is to delete the updated time sensitive networking schedule in response to a message from the compute node indicating a first set of constraints is not met by the updated time sensitive networking schedule.
- Example 33 includes the subject matter of any one of examples 29 to 32, wherein the central user configurator is to: (i) determine whether the central network configurator supports generation of the updated time sensitive networking schedule based on a first one of the set of parameters; and (ii) discard the first one of the set of parameters when the central network configurator does not support generation of the updated time sensitive networking schedule based on the first one of the set of parameters.
- Example 34 includes the subject matter of any one of examples 29 to 32, wherein the central user configurator is to: (i) determine whether the central network configurator supports generation of the updated time sensitive networking schedule based on a first one of the set of parameters; and (ii) replace the first one of the set of parameters with a different parameter when the central network configurator does not support generation of the updated time sensitive networking schedule based on the first one of the set of parameters.
- Example 35 is at least one non-transitory computer readable medium comprising computer readable instructions which, when executed, cause at least one processor to at least: (i) parse a virtualized industrial function descriptor corresponding to a virtualized workload to determine a set of parameters for a second time sensitive networking schedule to be implemented by a softswitch on a compute node, the second time sensitive networking schedule different from a first time sensitive networking schedule already implemented by the softswitch on the compute node; (ii) determine the second time sensitive networking schedule based on the set of parameters; and (iii) send the second time sensitive networking schedule to the compute node.
- Example 36 includes the subject matter of example 35, wherein the instructions, when executed, cause the at least one processor to: (i) parse the virtualized industrial function descriptor to determine a virtual machine configuration specification for a virtual machine to deploy on the compute node to host the virtualized workload; and (ii) send the virtual machine configuration specification to the compute node to cause the virtual machine to be deployed on the compute node.
- Example 37 includes the subject matter of example 36, wherein the instructions, when executed, further cause the at least one processor to delete the virtual machine from the compute node in response to a message from the compute node indicating a first set of constraints is not met by the second time sensitive networking schedule.
- Example 38 includes the subject matter of example 35 or example 36, wherein the instructions, when executed, cause the at least one processor to delete the second time sensitive networking schedule in response to a message from the compute node indicating a first set of constraints is not met by the second time sensitive networking schedule.
- Example 39 is a method to change a time sensitive networking schedule implemented by a softswitch on a compute node. The method of example 39 includes parsing a virtualized industrial function descriptor corresponding to a virtualized workload to determine a set of parameters for an updated time sensitive networking schedule to be implemented by the softswitch. The method of example 39 also includes determining the updated time sensitive networking schedule based on the set of parameters. The method of example 39 further includes sending the updated time sensitive networking schedule to the compute node.
- Example 40 includes the subject matter of example 39, and further includes (i) parsing the virtualized industrial function descriptor to determine a virtual machine configuration specification for a virtual machine to deploy on the compute node to host the virtualized workload; and (ii) sending the virtual machine configuration specification to the compute node to cause the virtual machine to be deployed on the compute node.
- Example 41 includes the subject matter of example 40, and further includes deleting the virtual machine from the compute node in response to a message from the compute node indicating a first set of constraints is not met by the updated time sensitive networking schedule.
- Example 42 includes the subject matter of example 39 or example 40, and further includes deleting the updated time sensitive networking schedule in response to a message from the compute node indicating a first set of constraints is not met by the updated time sensitive networking schedule.
- Example 43 is an apparatus including means for parsing a virtualized industrial function descriptor corresponding to a virtualized workload to determine a set of parameters for a second time sensitive networking schedule to be implemented by a softswitch on a compute node, the second time sensitive networking schedule different from a first time sensitive networking schedule already implemented by the softswitch on the compute node. The apparatus of example 43 also includes means for determining the second time sensitive networking schedule based on the set of parameters, the means for determining the second time sensitive networking schedule to send the second time sensitive networking schedule to the compute node.
- Example 44 includes the subject matter of example 43, and further includes means for determining a virtual machine configuration specification for a virtual machine to deploy on the compute node to host the virtualized workload, the means for determining the virtual machine configuration specification to: (i) parse the virtualized industrial function descriptor to determine the virtual machine configuration specification; and (ii) send the virtual machine configuration specification to the compute node to cause the virtual machine to be deployed on the compute node.
- Example 45 includes the subject matter of example 44, wherein the means for determining the virtual machine configuration specification is further to delete the virtual machine from the compute node in response to a message from the compute node indicating a first set of constraints is not met by the updated time sensitive networking schedule.
- Example 46 includes the subject matter of example 43 or example 44, wherein the means for determining the second time sensitive networking schedule is further to delete the second time sensitive networking schedule in response to a message from the compute node indicating a first set of constraints is not met by the second time sensitive networking schedule.
- Example 47 includes the subject matter of any one of examples 1 to 7, wherein the second softswitch is a duplicate of the first softswitch when the second softswitch is initially deployed on the compute node by the network node configurator.
- Example 48 includes the subject matter of any one of examples 8 to 14, wherein the second softswitch is a duplicate of the first softswitch when the second softswitch is initially deployed on the compute node.
- Example 49 includes the subject matter of any one of examples 15 to 21, wherein the second softswitch is a duplicate of the first softswitch when the second softswitch is initially deployed on the compute node.
- Example 50 includes the subject matter of any one of examples 22 to 28, wherein the second softswitch is a duplicate of the first softswitch when the second softswitch is initially deployed on the compute node.
- Although certain example methods, apparatus and articles of manufacture have been disclosed herein, the scope of coverage of this patent is not limited thereto. On the contrary, this patent covers all methods, apparatus and articles of manufacture fairly falling within the scope of the claims of this patent.
- The following claims are hereby incorporated into this Detailed Description by this reference, with each claim standing on its own as a separate embodiment of the present disclosure.
Claims (33)
Priority Applications (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US16/586,391 US11012365B2 (en) | 2019-09-27 | 2019-09-27 | Changing a time sensitive networking schedule implemented by a softswitch |
US17/229,588 US20210328941A1 (en) | 2019-09-27 | 2021-04-13 | Changing a time sensitive networking schedule implemented by a softswitch |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US16/586,391 US11012365B2 (en) | 2019-09-27 | 2019-09-27 | Changing a time sensitive networking schedule implemented by a softswitch |
Related Child Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US17/229,588 Continuation US20210328941A1 (en) | 2019-09-27 | 2021-04-13 | Changing a time sensitive networking schedule implemented by a softswitch |
Publications (2)
Publication Number | Publication Date |
---|---|
US20200028791A1 true US20200028791A1 (en) | 2020-01-23 |
US11012365B2 US11012365B2 (en) | 2021-05-18 |
Family
ID=69162149
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US16/586,391 Active 2039-10-22 US11012365B2 (en) | 2019-09-27 | 2019-09-27 | Changing a time sensitive networking schedule implemented by a softswitch |
US17/229,588 Abandoned US20210328941A1 (en) | 2019-09-27 | 2021-04-13 | Changing a time sensitive networking schedule implemented by a softswitch |
Family Applications After (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US17/229,588 Abandoned US20210328941A1 (en) | 2019-09-27 | 2021-04-13 | Changing a time sensitive networking schedule implemented by a softswitch |
Country Status (1)
Country | Link |
---|---|
US (2) | US11012365B2 (en) |
Cited By (11)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN111488631A (en) * | 2020-06-28 | 2020-08-04 | 中国核动力研究设计院 | Nuclear-level security display device and configuration-analysis system thereof |
CN113098895A (en) * | 2021-04-26 | 2021-07-09 | 成都中恒星电科技有限公司 | DPDK-based network traffic isolation system |
US11265834B2 (en) * | 2019-10-10 | 2022-03-01 | Acer Incorporated | Base stations and methods for time-sensitive networking (TSN) clock information delivery |
US20220239397A1 (en) * | 2021-01-25 | 2022-07-28 | Marvell Israel (M.I.S.L) Ltd. | Centralized control of time gates for time sensitive networking (tsn) |
CN115150274A (en) * | 2022-09-06 | 2022-10-04 | 国网湖北省电力有限公司电力科学研究院 | Unified configuration method, system and storage medium for time-sensitive network equipment |
CN115277306A (en) * | 2022-06-27 | 2022-11-01 | 重庆邮电大学 | Joint scheduling method for time-sensitive network and industrial wireless network based on successive approximation |
EP4099633A1 (en) * | 2021-06-01 | 2022-12-07 | Siemens Aktiengesellschaft | Automated application service detection for configuring industrial networks |
WO2022262465A1 (en) * | 2021-06-18 | 2022-12-22 | 重庆邮电大学工业互联网研究院 | Opc ua-based centralized user configuration method and system for time sensitive network |
US11625199B2 (en) * | 2019-11-14 | 2023-04-11 | Kabushiki Kaisha Toshiba | Communication apparatus, communication method, and computer program product |
US20230152765A1 (en) * | 2021-11-16 | 2023-05-18 | Johnson Controls Tyco IP Holdings LLP | Building data platform with schema extensibility for states of a digital twin |
US11796974B2 (en) | 2021-11-16 | 2023-10-24 | Johnson Controls Tyco IP Holdings LLP | Building data platform with schema extensibility for properties and tags of a digital twin |
Families Citing this family (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CA3124355A1 (en) * | 2019-02-06 | 2020-08-13 | Fermat International, Inc. | Analytics, algorithm architecture, and data processing system and method |
Family Cites Families (13)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
FR2948247B1 (en) * | 2009-07-16 | 2011-12-09 | Univ Paris Curie | METHOD AND SYSTEM FOR HIGH PERFORMANCE AND AUTOMATED MANAGEMENT OF VIRTUAL NETWORKS. |
US10069707B2 (en) * | 2012-05-29 | 2018-09-04 | Openet Telecom Ltd. | System and method for seamless horizontal scaling using logical scalable units |
US9465637B2 (en) * | 2013-03-29 | 2016-10-11 | Dell Products, Lp | System and method for automating virtual network provisioning |
US9600386B1 (en) * | 2013-05-31 | 2017-03-21 | Sandia Corporation | Network testbed creation and validation |
EP3281112A4 (en) * | 2015-04-09 | 2018-11-14 | Level 3 Communications, LLC | Network service infrastructure management system and method of operation |
CN105357039B (en) * | 2015-10-27 | 2019-01-18 | 中国船舶重工集团公司第七二二研究所 | A kind of emulation mode and device of time delay tolerant network |
WO2017155545A1 (en) * | 2016-03-11 | 2017-09-14 | Tektronix Texas, Llc. | Timestamping data received by monitoring system in nfv |
CN109074280B (en) * | 2016-04-29 | 2023-11-17 | 苹果公司 | Network function virtualization |
WO2018015425A1 (en) * | 2016-07-19 | 2018-01-25 | Schneider Electric Industries Sas | Time-sensitive software defined networking |
JP6740911B2 (en) * | 2017-01-16 | 2020-08-19 | 富士通株式会社 | Port switching program, port switching method, and information processing device |
US10574595B2 (en) * | 2017-09-28 | 2020-02-25 | Argela Yazilim ve Bilisim Teknolojileri San. ve Tic. A.S. | System and method for elastic scaling of virtualized network functions over a software defined network |
US10608893B2 (en) * | 2017-12-06 | 2020-03-31 | Nokia Technologies Oy | SDN control plane performance testing |
US11128556B2 (en) * | 2019-02-20 | 2021-09-21 | Accenture Global Solutions Limited | Deploying, testing, monitoring, scaling, and healing virtual network functions in a software-defined network |
-
2019
- 2019-09-27 US US16/586,391 patent/US11012365B2/en active Active
-
2021
- 2021-04-13 US US17/229,588 patent/US20210328941A1/en not_active Abandoned
Cited By (12)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US11265834B2 (en) * | 2019-10-10 | 2022-03-01 | Acer Incorporated | Base stations and methods for time-sensitive networking (TSN) clock information delivery |
US11625199B2 (en) * | 2019-11-14 | 2023-04-11 | Kabushiki Kaisha Toshiba | Communication apparatus, communication method, and computer program product |
CN111488631A (en) * | 2020-06-28 | 2020-08-04 | 中国核动力研究设计院 | Nuclear-level security display device and configuration-analysis system thereof |
US20220239397A1 (en) * | 2021-01-25 | 2022-07-28 | Marvell Israel (M.I.S.L) Ltd. | Centralized control of time gates for time sensitive networking (tsn) |
CN113098895A (en) * | 2021-04-26 | 2021-07-09 | 成都中恒星电科技有限公司 | DPDK-based network traffic isolation system |
EP4099633A1 (en) * | 2021-06-01 | 2022-12-07 | Siemens Aktiengesellschaft | Automated application service detection for configuring industrial networks |
WO2022253538A1 (en) * | 2021-06-01 | 2022-12-08 | Siemens Aktiengesellschaft | Automated application service detection for configuring industrial communication networks |
WO2022262465A1 (en) * | 2021-06-18 | 2022-12-22 | 重庆邮电大学工业互联网研究院 | Opc ua-based centralized user configuration method and system for time sensitive network |
US20230152765A1 (en) * | 2021-11-16 | 2023-05-18 | Johnson Controls Tyco IP Holdings LLP | Building data platform with schema extensibility for states of a digital twin |
US11796974B2 (en) | 2021-11-16 | 2023-10-24 | Johnson Controls Tyco IP Holdings LLP | Building data platform with schema extensibility for properties and tags of a digital twin |
CN115277306A (en) * | 2022-06-27 | 2022-11-01 | 重庆邮电大学 | Joint scheduling method for time-sensitive network and industrial wireless network based on successive approximation |
CN115150274A (en) * | 2022-09-06 | 2022-10-04 | 国网湖北省电力有限公司电力科学研究院 | Unified configuration method, system and storage medium for time-sensitive network equipment |
Also Published As
Publication number | Publication date |
---|---|
US11012365B2 (en) | 2021-05-18 |
US20210328941A1 (en) | 2021-10-21 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US11012365B2 (en) | Changing a time sensitive networking schedule implemented by a softswitch | |
US11106838B2 (en) | Systems, methods, and apparatus to generate an integrated modular architecture model | |
KR101614052B1 (en) | System and method for configuring cloud computing systems | |
CN104541247B (en) | System and method for adjusting cloud computing system | |
CN117501246A (en) | System and method for autonomous monitoring in an end-to-end arrangement | |
WO2019148960A1 (en) | Data analysis device, system, and method | |
CN107210928A (en) | Distributed and self-adaptive computer network analysis | |
GB2523338A (en) | Testing a virtualised network function in a network | |
CN107846443B (en) | Distributed processing in a network | |
Garbugli et al. | TEMPOS: QoS management middleware for edge cloud computing FaaS in the Internet of Things | |
Calarco et al. | On the effectiveness of linux containers for network virtualization | |
US20230353467A1 (en) | Methods and apparatus for determining low latency network connectivity in computing systems | |
Rezabek et al. | Engine: Flexible research infrastructure for reliable and scalable time sensitive networks | |
CN100568195C (en) | A kind of monitoring method of (SuSE) Linux OS process scheduling information | |
CN112202595A (en) | Abstract model construction method based on time sensitive network system | |
Rizou et al. | A service platform architecture enabling programmable edge-to-cloud virtualization for the 5G Media industry | |
JP2021012405A (en) | Control system, setting device and computer program | |
CN114337893A (en) | Precise time synchronization method based on programmable data plane | |
Raith et al. | faas‐sim: A trace‐driven simulation framework for serverless edge computing platforms | |
Denzler et al. | Timing analysis of tsn-enabled opc ua pubsub | |
CN112202596A (en) | Abstract model construction device based on time sensitive network system | |
Garbugli | QoS-aware architectures, technologies, and middleware for the cloud continuum | |
US20220224624A1 (en) | Methods, apparatus, and articles of manufacture to improve bandwidth for packet timestamping | |
US20230344739A1 (en) | Methods and apparatus to generate an egress timestamp | |
US20230403568A1 (en) | Methods and apparatus to slice networks for wireless services |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
FEPP | Fee payment procedure |
Free format text: ENTITY STATUS SET TO UNDISCOUNTED (ORIGINAL EVENT CODE: BIG.); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: DOCKETED NEW CASE - READY FOR EXAMINATION |
|
AS | Assignment |
Owner name: INTEL CORPORATION, CALIFORNIA Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:MCGRATH, MICHAEL;SPOCZYNSKI, MARCIN;NOLAN, MICHAEL;AND OTHERS;SIGNING DATES FROM 20190926 TO 20190927;REEL/FRAME:052317/0409 |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: NOTICE OF ALLOWANCE MAILED -- APPLICATION RECEIVED IN OFFICE OF PUBLICATIONS |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: PUBLICATIONS -- ISSUE FEE PAYMENT RECEIVED |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: PUBLICATIONS -- ISSUE FEE PAYMENT VERIFIED |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: PUBLICATIONS -- ISSUE FEE PAYMENT VERIFIED |
|
STCF | Information on status: patent grant |
Free format text: PATENTED CASE |