Routing Full Motion Video (FMV) Streams in One-Way Transfer Systems Using Out-of-Band Routing Tables

Abstract

The examples of this disclosure describe a system and method relating to full-motion video (FMV) routing in a one-way forwarding (OWT) system. The technique reserves a specific channel for the transmission of a video stream and transmits the video stream from a low-reliability computing environment to a high-reliability computing environment along the data path defined by that channel. When the video stream is received on the high-reliability side, the channel on which the video stream was received is determined and used to query a routing table that returns the destination address of the destination device to which the video stream should be transmitted. The video stream is then delivered to the destination device having the corresponding address.

Description

Background Art

[0001] Background

[0001] In data transfer and communication systems, communication is generally performed in a bidirectional manner. For example, two devices communicating with each other exchange data bidirectionally. This ability enables confirmation or positive response that the data is correctly received and processed. If the data is not correctly received or processed due to packet loss or data corruption, etc., the receiving device can request retransmission of the data. In a system where only unidirectional communication is implemented, such positive response or request for retransmission of data is not available.

[0002]

[0002] With respect to these and other general considerations, aspects disclosed herein have been devised. Further, although relatively specific problems may be described, it should be understood that those examples should not be limited to solving the specific problems identified in the background or other parts of the present disclosure.

Summary of the Invention

[0003] Summary

[0003] Examples of the present disclosure describe systems and methods relating to full-motion video (FMV) routing in a one-way transmission (OWT) system. To help ensure that the video stream is processed correctly and is resilient to failures in the system's equipment, the OWT system includes components that restrict the flow of data in one direction through the system while providing additional reliability enhancements. For example, the system may include a transmitting computing device having an optical transmitter dedicated to transmission-only functions. The technique reserves a specific channel for the transmission of a video stream and transmits the video stream from a low-reliability computing environment to a high-reliability computing environment along the data path defined by that channel. When the video stream is received on the high-reliability side, the channel on which the video stream is received is determined and used to query a routing table that returns the destination address of the destination device to which the video stream should be transmitted. The video stream is then delivered to the destination device having the corresponding address. As a result, even if the source device in the low-reliability computing environment does not know the destination address, the video stream can still be routed properly through the OWT into the high-reliability computing environment.

[0004]

[0004] This summary is provided to introduce in a simplified form a set of concepts that will be further described in the following detailed description. This summary is not intended to identify any major or essential features of the claims, nor is it intended to be used to limit the scope of the claims. Additional aspects, features, and / or advantages of the examples are partially described in the following description, partially revealed from the description, or may be known by the practice of this disclosure.

[0005] Brief explanation of the drawing

[0005] An example is given with respect to the following drawings. [Brief explanation of the drawing]

[0006] [Figure 1]

[0006] An example of a one-way forwarding (OWT) system for full-motion video routing is shown. [Figure 2]

[0007] This shows an example of data flow for multiple video streams through an example of an OWT system. [Figure 3]

[0008] This shows an example of a fault-tolerant video streaming core in a one-way transmission system. [Figure 4]

[0009] This document presents an example of a method for full-motion video routing using an out-of-band routing table. [Figure 5]

[0010] This block diagram shows an example of a physical component of a computing device for implementing aspects of this disclosure. [Modes for carrying out the invention]

[0007] Detailed explanation

[0011] A one-way data transfer system (OWT) refers to a computing system that uses one or more data diodes to ensure that data can only be transferred in one direction through the individual computing devices of the computing system. In this example, the data diodes ensure one-way data packet transfer through the implementation of hardware and / or software components such as a dedicated network interface card (NIC).

[0008]

[0012] OWT systems can be used to protect networks or endpoints from outbound data transmission, malicious inbound data transmission (e.g., viruses and malware), and cyberattacks. For example, an OWT system facilitates data transfer between endpoints in low-reliability computing environments (such as the public internet or other high-threat environments) and endpoints in high-reliability computing environments (or computing environments with higher security than those in low-reliability environments). In such an example, the OWT system spans or includes multiple computing environments separated by one or more boundaries between low-reliability and high-reliability computing environments.

[0009]

[0013] For example, a highly trusted environment could be a system or network where devices, applications, and users are considered trustworthy, and security measures are in place to establish and maintain that trust. In this type of environment, devices, software, and the devices and / or parties involved, such as users, often adhere to authenticated, approved, and / or established security policies and best practices. Highly trusted environments typically have strict access controls, encryption, and monitoring to ensure that trust is maintained and minimize the risk of unauthorized access, data breaches, or other security incidents. Devices within a highly trusted environment may be authorized to access or be accessed by other devices based on security techniques implemented by the highly trusted environment (e.g., unique encryption keys, secrets, or other cryptographic techniques). For example, communications transmitted through a highly trusted environment may be considered trustworthy by other computing environments or devices based on the fact that the highly trusted environment (and its devices) are included in an allow list (e.g., a list of approved devices and / or computing environments). Alternatively, communications transmitted through a highly trusted environment may be considered trustworthy based on passwords or credentials provided with the communications. In some cases, devices in a highly reliable environment do not require authentication to access or be accessed by other devices. A highly reliable environment generally does not expose the security techniques it implements to other computing environments that it may consider to be less reliable or unreliable.

[0010]

[0014] In contrast, a low-trust or untrusted environment may be a system or network where devices, applications, and / or users are not implicitly trusted, or where there is a high risk of unauthorized access or malicious activity. Such environments may have limited or no security measures in place, or may be connected to a large number of external or unmanaged devices. Alternatively, a low-trust or untrusted environment may also refer to an environment where devices are not considered protected or trusted by other devices within and / or outside such an environment. Because security techniques implemented in a high-trust environment are not exposed to a low-trust or untrusted environment, a low-trust or untrusted environment may not be able to access or communicate with a high-trust environment without performing various authorization and / or authentication steps that do not need to be performed by devices within the high-trust environment.

[0011]

[0015] Because OWT systems involve one-way data transmission, there is no confirmation that data transmitted over the one-way transmission path has been received by the receiving device and / or processed correctly by the receiving device. In contrast, bidirectional systems can use communication protocols such as the Transmission Control Protocol (TCP), which can send back acknowledgments to the transmitting device. For example, in TCP, once a connection is established between two devices, they exchange a series of messages to synchronize and establish connection parameters. Then, when the transmitting device sends data, the receiving device sends back an acknowledgment (ACK) message to the transmitting device to confirm that the data has been received. If the transmitting device does not receive an ACK within a certain time, the transmitting device retransmits the data. In OWT systems, such ACK messages are impossible because the receiving device cannot send back communication to the transmitting device. Instead, one-way communication protocols such as the User Datagram Protocol (UDP) must be used for communication. As a result, a robust system is needed to help ensure that the data transmitted from the transmitting device is actually received by the receiving device and processed correctly. Without such a system, the reliability of the system is significantly reduced.

[0012]

[0016] In addition, due to the OWT scenario and the separation of low-reliability and high-reliability environments, the final destination is unknown to the source device in the low-reliability environment. For example, if a video stream from the low side is to be sent to a specific destination on the high side, the actual address of the destination device is generally unknown to the low-side device because its IP address is concealed or protected from the low-side device. As a result, routing data from the low side to the high side becomes particularly difficult, as only devices in the high-reliability environment may have access to the destination address, and routing becomes virtually blind. For example, a video source device may know the address of another intermediate device on the low side, but the video source does not know the address of the final destination. Furthermore, the intermediate device may also not know the address of the final destination. These challenges are exacerbated with live video streams that do not have disparate package lengths (e.g., unknown end time) through which routing must be continuously managed over the unknown duration of the video stream.

[0013]

[0017] This technology provides a solution to the above problem by reserving a specific video channel and routing the video stream based on the specific channel on which it is received. For example, when attempting to establish a new video stream, a channel in the OWT system is requested, and a globally unique identifier (GUID) associated with the video stream is provided with the request. The channel is then reserved for that specific video stream and GUID. As the video stream is transmitted from the source computing environment to the destination environment, a device in the destination environment monitors the channel reserved for the video stream. The device determines the destination address of the video stream based on the GUID. The video stream is then delivered to the destination device having the corresponding source address. As a result, even if the source device does not know the destination address, the video stream can travel through the OWT system into the highly reliable computing environment and be properly routed within it.

[0014]

[0018] Figure 1 shows an example of an OWT system 100 for full-motion video routing. The presented system 100 is a combination of interdependent components that interact to form an integrated whole. The components of system 100 may be hardware components or software components (e.g., application programming interfaces (APIs), modules, runtime libraries) that are implemented on and / or executed by the hardware components of system 100. In one example, the components of system 100 are distributed across multiple processing units or computing systems.

[0015]

[0019] System 100 represents an OWT system for transmitting video streams between different computing environments. System 100 includes a first computing environment 101 and a second computing environment 103. In some examples, computing environments 101 and 103 are implemented by a cloud computing environment or another type of distributed computing environment and are subject to one or more distributed computing models / services (e.g., Infrastructure as a Service (IaaS), Platform as a Service (PaaS), Software as a Service (SaaS), Function as a Service (FaaS)). In some examples, each environment is a separate network or subnetwork.

[0016]

[0020] Figure 1 depicts a specific combination of computing environment and equipment, but the size and structure of the equipment and computing environment described herein can vary and may include additional or fewer components than those shown in Figure 1. Furthermore, although the examples presented herein are described in the context of data transfer between an OWT system and a low-reliability computing environment and a high-reliability computing environment, these examples are also applicable to other types of data transfer between computing environments of various (or the same) types and security levels. For example, the first computing environment 101 may also be called the source computing environment, and the second computing environment 103 may be called the destination computing environment.

[0017]

[0021] The first environment 101 includes video sources such as a source camera 102A or another computing device 102B that generates video data (such as a shared screen or computer-generated video). The source camera 102A may be any type of camera capable of capturing and streaming video data, such as a drone camera, security camera, or wearable camera. The first environment also includes a source video broker 104 (sometimes referred to as the low video broker 104 in this example) that accesses or stores the low side or source FMV mapping table 114. The video stream is transmitted from the low video broker via the fault-tolerant OWT core 106, and the video stream is received by a guard 108 in the second environment 103. The guard 108 transmits the video stream to a destination video broker 110 (sometimes referred to as the high video broker 110 in this example) in the second environment 103 that accesses or uses the high side or destination FMV routing table 116. The high-video broker 110 uses the high-side FMV routing table 116 to identify the destination addresses of one or more destinations, such as display devices 112A-112E, of the high-side destination devices 112A-112E in the second computing environment 103. The high-side destination devices 112A-E may include devices such as display devices 112A-C for displaying the video stream and / or storage devices 122D-E for storing the video stream. Other types of destination devices 112 may also be possible, such as devices for processing and / or analyzing the received video stream.

[0018]

[0022] The first computing environment 101 may represent a low-reliability computing environment in which the devices running within computing environment 101 are not trusted by the devices running within the second computing environment 103. In such an example, the first computing environment 101 may be physically separated from the second computing environment 103, such that the first computing environment 101 is located in a first physical location (e.g., a region, building, room, and / or server rack) and the second computing environment 103 is located in one or more other physical locations. Alternatively, in other examples, computing environments 101 and 103 are all located in the same physical location.

[0019]

[0023] Video source 102 captures or generates video that is converted into a video stream, which may have various formats. For example, the video stream may be in the Moving Picture Experts Group (MPEG) Transport Stream (TS) format. In other examples, the video stream may be in the Real-Time Transport Protocol (RTP) format, the Real-Time Streaming Protocol (RTSP) format, or other similar formats.

[0020]

[0024] The video stream is then received by the raw video broker 104. The raw video broker 104 is a computer device, such as a server, that processes the received video stream and transmits it. The transmission of the received video stream is based on a specific GUID of the specific video stream being received. For example, a received video stream is transmitted across specific channels based on the specific GUID of the video stream. Information on which channels to transmit the video stream on based on the GUID can be stored in the raw-side FMV mapping table 114, which contains data from a user (e.g., a customer) or administrator in the second environment 103. For example, when a new video stream from source to destination (e.g., low to high) is requested, the virtual machine is provisioned to receive and process the new video stream on a specific IP address and port, which may be called an ingress IP address and / or ingress port. The GUID, ingress IP address, and port of the new video stream can be provisioned in the raw-side FMV mapping table 114. The data in the raw-side FMV mapping table 114 indicates a specific GUID, also referred to herein as a data flow ID, for each video stream received by the raw video broker 104. For example, a specific GUID can be assigned to each ingress IP address and port from which a particular data stream is received. The raw video broker 104 then monitors the video feed on the assigned port or from the assigned IP address.

[0021]

[0025] When a new video stream is requested, a new channel command or request can be transmitted through the fault-tolerant OWT core 106 and within the second computing environment 103, and the new channel command is received by the orchestrator 105 (which may be another device or whose function may be incorporated into another device such as the high video blocker 110). In response to this request, the orchestrator 105 reserves an unused channel for the new video stream and stores that information in the high-side routing table 116. For example, the high-side routing table 116 stores pairs of GUIDs and corresponding reserved channel numbers. As further discussed below, when the high video blocker 110 receives a video stream on a particular channel, the high video blocker 110 queries the high-side mapping table 116 using that channel number to determine the GUID of the video stream. The high-side mapping table 116 can also store the destination address of the video stream corresponding to each GUID.

[0022]

[0026] Different channels of the OWT system may include specific paths for data to propagate through the system. For example, guard 108 can have a fixed set of video channels, and there can be approximately 10 video channels for each graphics processing unit (GPU) of guard 108. A given video channel can have a static input port and a static destination or output port. The static input port receives a specific video stream, and that specific video channel can continue to process the video stream over the duration of the stream. The static destination of all video channels of guard 108 can be a specific port of high video blocker 110. Thus, in some examples, each channel is defined by (1) a specific guard that receives / transmits a video stream and (2) a specific output port of that guard. For example, channel 1 can be defined as guard 1 and port 1. Channel 2 can be defined as guard 1 and port 2. Channel 11 can be defined as guard 2 and port 2 of guard 2. Each of these channels can be predefined. As additional guards and devices are implemented, the number of channels continues to increase.

[0023]

[0027] When orchestrator 105 receives a new channel command, orchestrator 105 queries a list of predefined channels to determine an open or unused channel. Then, an entry in high - side FMV routing table 116 that correlates that channel to the GUID provided within the new channel command is created or edited. Then orchestrator 105 can transmit a confirmation message to confirm that the channel is reserved and a video stream can be transmitted. In the example, the confirmation message is transmitted to the second computing environment 103 and the confirmation message is received by source video blocker 104. A corresponding entry in low - side FMV mapping table 114 that correlates the reserved channel to a specific GUID can also be created.

[0024]

[0028] In some examples, the transmission of acknowledgment messages utilizes a second fault-tolerant OWT core 107 that transmits data in the reverse direction from a first fault-tolerant OWT core 106. The acknowledgment messages can also be transmitted via a second guard 109, which is responsible for preventing inappropriate data (e.g., private or confidential data) from leaving the second computing environment 103.

[0025]

[0029] A new channel request is sent separately from and before the video stream, and channel reservations for the video stream are similarly made before the video stream is received. In this way, the new channel command and channel reservation processes can be considered out-of-band communication and processes.

[0026]

[0030] Once the channel reservation is complete, the source video broker 104 receives the corresponding video stream. Upon receiving the video stream, the source video broker 104 identifies the GUID based on the low-side FMV mapping table 114 and the ingress port and / or ingress IP address of the source video broker 104 that received the video stream. Based on the GUID, the reserved channel of the video stream is also identified from the low-side FMV mapping table 114. The source video broker 104 then transmits the video stream over the reserved channel. For example, the source video broker 104 propagates the video stream through the fault-tolerant OWT core 106 and guard 108 along the data path defined by the reserved channel.

[0027]

[0031] Guard 108 protects the second computing environment 103 from data entering the second computing environment 103 from the first computing environment 101. Guard 108 performs modifications and / or inspections of the video stream. For example, in some cases, Guard 108 transcodes the video stream. Alternatively, Guard 108 performs security checks or policy enforcement on the video stream to remove malicious data or any other type of data in accordance with policies set by the administrator of the second computing environment 103. As an example, Guard 108 performs schema enforcement of data, such as enforcing a schema for a specific video stream format. If the video stream meets the criteria set by Guard 108, Guard 108 further transmits the video stream to the high video broker 110 from the port defined by the reserved channel. Thus, Guard 108 itself does not need to know or determine the final destination of the video stream in the second environment 103. Instead, the guard 108 simply outputs the video stream on the port via the reserved channel, and the high video broker 110 receives the video stream from the output port of the guard 108.

[0028]

[0032] When the high video broker 110 receives a video stream, it determines the channel on which the video stream was received. Based on that specific channel, the high video broker 110 identifies the GUID of the video stream and the destination address (e.g., IP address or port) of the destination device 112 in the second computing environment 103 related to the video stream. For example, the high video broker 110 performs a lookup operation or query against the high-side FMV routing table 116 on the reserved channel, and the high-side FMV routing table 116 returns one or more destination addresses and / or GUIDs of video streams being transmitted on the reserved channel.

[0029]

[0033] Next, the high video broker 110 transmits the video stream to the identified destination address and destination device 112. Since the high video broker 110 and the destination device 112 are in the same second environment 103, bidirectional communication such as TCP can be used to transmit the video stream from the high video broker 110. Subsequently, the destination device 112 displays, stores, and / or processes the live video stream for the duration of the video stream.

[0030]

[0034] Figure 2 shows an example of the data flow of multiple video streams through an example of the OWT system 200. This example of system 200 may be substantially the same as or similar to system 100. However, in system 200, three guards 108A-C are depicted.

[0031]

[0035] In the illustrated data flow, three separate video streams are received and processed by the source video broker 104. The three video streams include a first video stream (VS1), a second video stream (VS2), and a third video stream (VS3). Before the video streams are processed and transmitted by the source video broker 104, a new channel command is sent for each video stream, and a different channel is reserved for each channel. In the illustrated example, channel 1 is reserved for VS1, channel 2 for VS2, and channel 3 for VS3. Corresponding entries are also created in the low-side FMV mapping table 114 and the high-side FMV routing table 116. Channel 1 is the default data path flowing through the first guard 108A. Channel 2 is the default data path flowing through the second guard 108B. Channel 3 is the default data path flowing through the third guard 108C.

[0032]

[0036] When the source video broker 104 receives VS1, it queries the low-side FMV mapping table 114 to determine that channel 1 is reserved for VS1. The source video broker 104 then transmits VS along the data path defined by channel 1 (e.g., via the fault-tolerant OWT core 106 and the first guard 108A). Similar operations are performed for VS2 and VS3 to transmit them along the data paths defined by channels 2 and 3, respectively.

[0033]

[0037] The high video broker 110 receives three video streams on three different channels. For example, the high video broker 110 receives VS1 from the first guard 108A, VS2 from the second guard 108B, and VS3 from the third guard 108C. Based on the channels received for each video stream, the high video broker 110 queries the high-side FMV routing table 116 to determine the destination address of a particular video stream.

[0034]

[0038] In the illustrated example, the high-video broker 110 queries the high-side FMV routing table 116 and determines that channel 1 corresponds to the destination address of the first destination device 112A. Therefore, the high-video broker 110 transmits VS1 to the first destination device 112A. The high-video broker 110 further queries the high-side FMV routing table 116 and determines that channel 2 corresponds to the destination address of the second destination device 112B. Therefore, the high-video broker 110 transmits VS2 to the second destination device 112B. The high-video broker 110 further queries the high-side FMV routing table 116 and determines that channel 3 corresponds to the destination address of the third destination device 112E. Therefore, the high-video broker 110 transmits VS3 to the third destination device 112C. As a result, even though the source video broker 104 has no knowledge of the final destination addresses of the various streams, the system of this technology can properly route the video streams to their respective destinations. Furthermore, this type of blind routing can be achieved without modifying the video stream itself or the corresponding datagrams and packets.

[0035]

[0039] If a video stream terminates or if a delay exceeding a threshold time occurs in the delivery of data stream packets, the reservation for a particular channel can be removed. In some examples, removing a reservation involves deleting the corresponding entry for the reserved channel in the high-side FMV routing table 116 and / or the low-side FMV mapping table 114. Removing a reservation not only frees up the channel for use by other video streams but also prevents the inappropriate forwarding of the received video stream to the wrong destination device. For example, when VS1 terminates (which can be detected by identifying the termination indicator in the video stream packets), the reservation for channel 1 is removed. Subsequently, if channel 1 is not reserved for a new video stream and that new video stream is received on channel 1, the high video broker 110 drops (e.g., deletes) or stores the new video stream instead of transmitting it to the first destination device 112A.

[0036]

[0040] Figure 3 shows an example of a fault-tolerant video streaming core 300 in a one-way transmission system. In the illustrated example, core 300 is an example of a system that includes the fault-tolerant OWT core 106 and guard 108 of system 100 in Figure 1.

[0037]

[0041] Figure 3 again shows the first computing environment 301 and the second computing environment 303. In the illustrated example, the first computing environment 301 includes a computing device 308. The computing device 308 may be referred to herein as the low-side computing device 308 or the transmitting device 308. The low-side computing device 308 receives a video stream 310 from a low-side broker (not shown in Figure 3). The low-side computing device 308 can serialize the video stream 310 by separating it into one or more data chunks using a file segmentation service or utility that is implemented locally on the computing device 308 or can be accessed remotely by the computing device 308.

[0038]

[0042] Next, the segmented data of the video stream 310 is transmitted unidirectionally (e.g., optically) to a second computing environment 303. The second computing environment 303 includes computing devices 312 and 314. In some examples, computing devices 312 and 314 are located in close proximity to computing device 308 (e.g., in the same building or room). For example, computing devices 312, 314 and computing device 308 may be located in the same room of a data center, such that computing device 308 is located in a first data rack (e.g., a server rack or data cabinet) and computing devices 312 and 314 are located in a second data rack or on different shelves in the first data rack. In such examples, computing devices 308 and computing devices 312 and 314 may be directly connected via point-to-point cables, which may be optical, as will be discussed further herein.

[0039]

[0043] In some examples, computers 312 and 314 are also physically separated from each other to help ensure reliability and redundancy. For example, computers 312 and 314 may be in different server racks, different rooms, or different buildings, depending on different power sources. Therefore, if power to computer 312 is lost, power to the second computer 314 may still be available. In other examples, computers 312 and 314 are located away from computer 308 (for example, in different buildings or rooms).

[0040]

[0044] The computing devices 312 and 314 receive the video stream transmitted from the low-side computing device 308. Thus, in some examples, computing device 312 may be referred to herein as the first receiving device 312, and computing device 314 may be referred to herein as the second receiving device 314. The receiving devices 312 and 314 can also operate as guards, and the computing devices 312 and 314 may be referred to separately as the first guard 312 and the second guard 314, or cross-domain protection devices 312 and 314.

[0041]

[0045] Returning to the transmission of data between the low-side computer 308 and the guards 312 and 314, the one-way transfer of data from the low-side computer 308 to the guards 312 and 314 can be achieved optically. The use of optical transmission adds further speed, reliability, and / or security to the data transfer. In the illustrated example, the low-side computer 308 includes an optical transmitter 309 that converts the segmented data of the video stream 310 into optical signals to be transmitted in the first optical fiber 311. For example, the optical transmitter 309 can encode the segmented data of the video stream 310 into a series of optical pulses.

[0042]

[0046] In general, fiber optic communication is a method of transmitting information from one location to another using optical signals transmitted through optical fibers. Optical fibers are typically thin strands of glass or plastic designed to guide light along their length. Optical fibers offer many advantages, including high speed and the ability to transmit data with little loss of signal strength. In addition, fiber optic communication is more secure than other forms of communication because it is difficult to intercept and tamper with signals transmitted through optical fibers.

[0043]

[0047] The optical transmitter 309 may be part of a dedicated transmission NIC or another circuit board that includes dedicated transmission functionality. For example, the circuit board may not have the ability to receive optical data. In another example, even if the circuit board includes an optical receiver, neither of the optical fibers of guards 312 and 314 is connected to the receiver, and therefore data reception by the optical receiver is impossible. For example, a dedicated transmission NIC transmits data to an endpoint, but cannot receive data from the endpoint because the receive pins on the network controller chip of the dedicated transmission NIC are physically disconnected. In some examples, the dedicated transmission NIC also includes firmware that keeps the link state of the dedicated transmission NIC always "up" (e.g., enabled and / or active). In yet another example, the dedicated transmission circuit is formed by attaching a splitter cable (e.g., a y-splitter cable), and the transmission signal is split into two cables, one of which is returned to the optical receiver of the transmitter circuit, thereby establishing a Layer 1 link state and causing the circuit to perceive a return data path even though there is actually no return data path. In yet another example, a rewritable gate array (FPGA) device or similar device can be configured to restrict data flow to only one direction (e.g., dedicated transmission). If one-way communication is required by a physical component (rather than a software-defined constraint), then one-way communication is considered physically enforced.

[0044]

[0048] Next, the optical signal generated by the optical transmitter 309 is split by the beam splitter 317. The beam splitter 317 splits the optical signal into multiple optical signals (for example, splitting the light transmitted through the first optical fiber 311). In the illustrated example, the optical signal is split into two split optical signals. One of the split optical signals is passed to the first receiving optical fiber 319, and the other split optical signal is passed to the second receiving optical fiber 321. Each of the split optical signals is a copy of the original optical signal and therefore contains the sample data as the original optical signal. In this example, the optical signal is split into two optical signals, but in other examples, the light may be split into even more signals.

[0045]

[0049] In some examples, the beam splitter 317 is a passive splitter that does not require power. For example, when light enters the beam splitter 317 from the first optical fiber 311, the light is split into the first receiving optical fiber 319 and the second receiving optical fiber 321 without requiring additional power. The passive beam splitter 317 splits the light by utilizing the reflective and / or refractive properties of the material, such as by using two glass prisms, semisilver mirrors, dichroic mirror prisms, or other suitable designs for splitting the beam of light, which are bonded or joined together to create a partial reflective surface.

[0046]

[0050] Since the passive beam splitter 317 does not require power to operate, using the passive beam splitter 317 also introduces greater reliability to the system. However, in other examples, an active or powered beam splitter 317 may be used. In some examples, the beam splitter 317 is located within the first computing environment 301 or the second computing environment 303. For example, the beam splitter 317 may be part of the low-side computing device 308 and / or part of the optical transmitter 309. In other examples, the beam splitter 317 is located within the second computing environment 303. For example, the beam splitter 317 may be incorporated into the guard 312, the second guard 314, and / or another device in the second computing environment 303.

[0047]

[0051] While beam splitter 317 is discussed herein primarily as a passive beam splitter, it may include other devices that split and / or duplicate optical signals, and in some examples may be powered. For example, beam splitter 317 may include a switch having a switched-port analyzer (SPAN) port. The SPAN port creates a copy or duplicate of data that can later be sent to another destination. As a result, the SPAN port may also be called a mirror port in some examples. The duplicate is created by monitoring the source port and duplicating the data received on the source port. Beam splitter 317 can also take the form of a test access point (TAP). A TAP is a passive hardware device that splits or copies data via a beam splitter or passive optical coupler that splits an optical signal into two separate paths.

[0048]

[0052] The segmented optical signals are then received in parallel by the first guard 312 and the second guard 314, respectively. More specifically, the segmented optical signals propagating through the first receiving optical fiber 319 are received by the first optical receiver 313 of the first guard 312, which is coupled to the first receiving optical fiber 319. The segmented optical signals propagating through the second receiving optical fiber 321 are received by the second optical receiver 315 of the second guard 314, which is coupled to the second receiving optical fiber 321. The optical receivers 313 and 315 convert the optical signals into electrical data signals that are substantially the same as the electrical signals representing the segmented data of the video stream 310 provided to the optical transmitter 309. The electrical data signals representing the segmented data of the video stream 310 can then be processed by the first guard 312 and the second guard 314, as will be discussed herein. In effect, overlapping video streams are thus received by the guards 312 and 314.

[0049]

[0053] If the first guard 312 determines that the video stream 310 satisfies the requirements of the second computing environment 303 (as discussed above), the first guard 312 transcodes and transmits the video stream to the first landing device 318. Similarly, if the second guard 314 determines that the video stream satisfies the requirements of the second computing environment, the second guard 314 transmits and transcodes the video stream to the second landing device 320. Therefore, if both guards 312 and 314 function properly and transmit the video stream 310, the landing devices 318 and 320 receive the duplicate video stream 310.

[0050]

[0054] Since the video stream 310 transmitted from the first computing environment 301 to the second computing environment 303 is unidirectional, it is not possible to send back an acknowledgment or a request for retransmission of the video stream (or part thereof) from the second computing environment 303 to the first computing environment 301. For example, if the first guard 312 or the first landing device 318 stops working (e.g., system crash, power outage), the low-side computing device 308 has no way of determining that the device is no longer functioning properly. To ensure that the video stream received by the second computing environment 303 is handled and processed with high fidelity, the second guard 314 and the second landing device 320 provide data redundancy for the video stream 310 transferred from the first computing environment 301 to the second computing environment 303 relative to the first guard 312 and the first landing device 318. Therefore, even if either the guard 312 or the second guard 314 (and / or the first landing device 318 or the second landing device 320) becomes inoperable, the other device can continue to process the video stream 310.

[0051]

[0055] To provide such data redundancy, the first landing device 318 and the second landing device 320 can communicate with each other, and this communication can be bidirectional (e.g., TCP) or unidirectional, depending on the implementation. In this example, the data to be communicated is called performance data 316.

[0052]

[0056] Performance data 316 indicates the performance and / or status of a specific device that is transmitting it, and / or data relating to the video stream being processed. For example, performance data 316 from the first landing device 318 indicates the status or performance of the first landing device 318. Performance data 316 from the second landing device 320 indicates the status or performance of the second landing device 320. In some examples, performance data 316 also provides status data for individual guards. For example, performance data 316 from the first landing device 318 may also indicate the operational status data of the first guard 312. Performance data 316 may also include the operational status data of the second guard 314. Thus, based on the status data 316, each of the first landing device 318 and the second landing device 320 can determine whether the other device is functioning properly.

[0053]

[0057] The first landing device 318 and / or the second landing device 320 change their operating state using performance data 316 to determine whether the first landing device 318 or the second landing device 320 is the source of the video stream 310 provided to the high video broker 325.

[0054]

[0058] In some examples, performance data 316 may include information such as uptime, processing speed, and bandwidth utilization. Alternatively, performance data 316 may also include transmission information for one or more periods. Examples of transmission information include the amount of data transmitted during that period, a list of data chunks, data segments, or packets transmitted for the video stream, data transmission metrics (e.g., average or maximum time to transfer video stream packets), the number of packets lost during transmission, and the current role or operating state of the computing device (e.g., primary or secondary device).

[0055]

[0059] The performance data 316 may also include data specific to the video stream 310 being processed by the first landing device 318 and the second landing device 320. For example, the performance data 316 may include data based on the continuity counter of the video stream 310. A continuity counter is a mechanism used in video streaming to ensure the correct ordering and consistency of data packets as they are transmitted across the network. For example, one example of a continuity counter may be used in the MPEG-TS format.

[0056]

[0060] For video streams in the MPEG-TS format, the continuity counter is a 4-bit field in the header of each transport stream packet (TSP). This counter is incremented by 1 for each consecutive packet carrying a payload belonging to the same Packetized Elementary Stream (PES) representing a single video, audio, or data stream within the transport stream. The continuity counter provides a method for identifying and managing packet loss, duplication, or reordering that may occur during transmission. In some examples, the counter increments between 1 and 16 and is reset to 1 for the next packet. In this technique, the first landing device 318 and the second landing device 320 can also create a secondary counter indicating which set of continuity counters has been received. The first set of 16 counts / packet can then be distinguished from the second set of 16 counts / packet (and other subsequent sets).

[0057]

[0061] As some additional detail, when the video stream 310 is first encoded within the first computing environment 301, the video stream 310 is broken down into smaller chunks and encapsulated into transport stream packets (TSPs) for transmission. Each TSP has a header containing information about the packet, such as a packet identifier (PID) that uniquely identifies the PES to which the packet belongs and a continuity counter that tracks the packet sequence within the PES. As the packet is transmitted, the continuity counter in the TSP header is incremented for each consecutive packet belonging to the same PES.

[0058]

[0062] Each of the first landing device 318 and the second landing device 320 can check the continuity counter of each received TSP. If the counter value is within the expected sequence, the first landing device 318 and the second landing device 320 can assume that the packets arrived in the correct order without loss or duplication. If the continuity counter value is outside the sequence, the first landing device 318 and the second landing device 320 can detect packet loss, duplication, or reordering.

[0059]

[0063] The analysis results of the continuity counters by the first landing device 318 and / or the second landing device 320 may be included in the performance data 316. In some examples, the continuity counter of each packet processed by the first landing device 318 and / or the second landing device 320 may be included in the performance data 316. For example, when the first landing device 318 processes a particular packet, the performance data 316 may show the packet's continuity counter value, which is an indicator that the packet was processed by the first landing device 318.

[0060]

[0064] In some examples, the first landing device 318 and the second landing device 320 operate as either primary or secondary devices. The primary device further transmits the video data 310 through the system, such as to the high video broker 325. The secondary device does not further transmit the received data through the system. For example, the secondary device may ultimately drop (e.g., delete or discard) the received video stream data. In other examples, the secondary device stores a copy of the video stream 310 for backup or restore purposes.

[0061]

[0065] The designation of whether the first landing device 318 or the second landing device 320 is a primary or secondary device depends on the performance data 316. In some examples, one of the landing devices 318, 320 may be designated as the primary device for all input video streams until the performance data 316 indicates that the primary device is no longer functioning properly. For example, the first landing device 318 may be designated as the primary device first, and the second landing device 320 as the secondary device.

[0062]

[0066] In such an example, the first landing device 318 maintains the operational state of its primary device until the second landing device 320 becomes inoperable or malfunctions. Criteria for determining whether the first landing device 318 is functioning correctly may be based on performance metrics of the first landing device 318, which may be represented in performance data 316. For example, health data and / or transmission information may be compared to one or more thresholds to determine whether the first landing device 318 is functioning properly or within acceptable limits. If performance data 316 is not received (for example, because the first landing device 318 is down), the performance data 316 can be considered to be outside the thresholds and may therefore indicate non-functionality of the first guard 312. Such determination may be made by the second landing device 320 based on the performance data 316 received from the first landing device 318. In addition, if the first landing device 318 does not receive performance data 316 from the first landing device 318 within a timeout period (e.g., a set duration), the second landing device 320 determines that the first landing device 318 is not functioning properly.

[0063]

[0067] If the second landing device 320 determines, based on performance data 316 (or lack thereof), that the first landing device 318 is not functioning properly, the second landing device 320 changes its operating state from secondary to primary and becomes the source of the video stream 310 to subsequent devices such as the high video broker 325. If the first landing device 318 is still partially operational, the second landing device 320 may indicate the change in operating state to the first guard 312 as part of the performance data 316. If the second landing device 320 is operating as primary, the second guard 314 further transmits the video stream through the system (e.g., to the high video broker 325), and the first landing device 318 does not transmit any further data.

[0064]

[0068] While the second landing device 320 is operating as the primary landing device, it can continue to transmit performance data 316 to the first landing device 318. In cases where the first landing device 318 is still operating (but with reduced performance), it can also continue to transmit performance data 316 to the second landing device 320. In some cases, the second landing device 320 continues to operate as the primary landing device even if the first landing device 318 has recovered adequate or acceptable performance (as indicated by the performance data 316). In such cases, the first landing device 318 can revert to being the primary landing device when the performance data 316 indicates that the second landing device 320 is no longer functioning properly. The determination that the second landing device 320 is not functioning properly may be similar to the determinations relating to the proper functioning of the first landing device 318 discussed above. For example, the first landing device 318 can compare performance data 316 from the second landing device 320 with one or more thresholds to determine whether the second landing device 320 is functioning properly.

[0065]

[0069] In another example, the second landing device 320 may revert to secondary mode when it detects that the first landing device 318 has regained functionality. Subsequently, the first landing device 318 resumes its operational state as primary mode. For example, based on performance data 316, the second landing device 320 can determine that the first landing device 318 has regained proper functionality. The second landing device 320 can then transmit a message (for example, as part of performance data 316) indicating that the first landing device 318 is about to resume operation as primary mode and that the second landing device 320 is switching its operational state to secondary mode.

[0066]

[0070] The switching of operating states can occur rapidly, and in some cases, the switching may occur in less than 100 milliseconds (ms). In some cases, the switching may occur on a packet-by-packet basis. For example, if the second landing device 320 is operating as a secondary device and receives a specific TS packet with a specific continuity count value, and performance data 316 indicates that the first landing device 318 did not process that particular packet, then the second landing device 320 will transmit that particular packet. The transmission of that particular packet may then be indicated in performance data 316. The first landing device 318 can remain in its primary state for subsequent packets, or the second landing device 320 can switch to being the primary device for subsequent packets, until there is another packet that is processed by one landing device but not by the other.

[0067]

[0071] In some cases, the landing devices 318 and 320 do not change their operating state. Rather, both landing devices 318 and 320 can transmit overlapping video streams to the switching device 323. Performance data 316 from each landing device 318 and 320 may also be provided to the switching device 323. The switching device 323 then switches between the primary video stream (e.g., the video stream from the first landing device 318) and the secondary enriched video stream (e.g., the video stream from the second landing device 320) and provides a single video stream to the high video broker 325.

[0068]

[0072] The switching device 323 effectively handles the overlapping video streams 310 coming from the first landing device 318 and the second landing device 320 as a primary video stream and a secondary video stream. The primary video stream is provided to the high video broker until an interruption to the primary video stream is detected. Once an interruption is detected, the secondary stream is then transmitted to the high video broker 325.

[0069]

[0073] Interruptions in the primary video stream can be based on the continuity counter and / or performance data 316 of the video stream. For example, if expected packets of video stream 310 are not received as part of the primary video stream, the switching device 323 can quickly switch to the secondary video stream and provide the secondary video stream to the high video broker 325. The switching device 323 can continue to provide the secondary video stream to the high video broker 325 until an interruption in the secondary video stream is detected by the switching device 323. Once an interruption in the secondary video stream is detected, the switching device 323 switches back to the primary video stream. Since the switching device 323 receives both the primary and secondary video streams simultaneously, the switching device 323 switches to the video stream with the fewest interruptions or the lowest frequency of dropped packets. Switching between the primary and secondary video streams can be performed quickly (e.g., less than 100ms). For example, in some cases, the switching is performed on a packet-by-packet basis.

[0070]

[0074] The switching between the primary and secondary video streams may be based on performance data 316, such as health data of the first landing device 318 or the second landing device 320. For example, if the performance data 316 indicates a performance degradation of the first landing device 318, the switching device 323 can switch to the secondary video stream even if the primary video stream has not yet encountered any interruptions.

[0071]

[0075] In such an example, the default channels discussed herein can still be identified by the IP addresses, ports, and / or the unique data paths of those channels within the system 300. Thus, the high video broker 110 can continue to distinguish video streams based on the channel on which the video stream is received.

[0072]

[0076] The OWT system 300 shown in Figure 3 is designed for use within the first fault-tolerant OWT core 106 in Figures 1 and 2, but the OWT system 300 can be substantially inverted to allow data to flow out and used in the second OWT core 107. In other examples, the fidelity of data flowing out of the second computing environment 103 may be less important than the fidelity of data flowing into the second computing environment 103 (e.g., video streams), so a simpler OWT system may be used in the second OWT core 107.

[0073]

[0077] Figure 4 shows an example of Method 400 for full-motion video routing. Method 400 can be performed by one or more of the devices discussed above, such as one or more of the devices shown in Figures 1 to 3.

[0074]

[0078] In operation 402, a new channel command or request is generated and / or received. The new channel command includes the GUID of the video stream received by the raw video broker. In some examples, the raw video broker generates the new channel command, or another device, such as an orchestrator, generates or receives the new channel command. For example, the new channel command may be transmitted over the control plane of the network of the OWT system discussed herein.

[0075]

[0079] In operation 404, in response to a new channel command, a channel is reserved for the video stream and its corresponding GUID. In some examples, reserving a channel involves querying several default channels to identify any open or currently unused channels. The identified channel is then reserved. Channel reservation also involves generating corresponding entries in the low-side mapping table and the high-side routing table. The entry in the low-side mapping table indicates a specific reserved channel corresponding to the GUID in the new channel command. The entry in the high-side routing table includes mappings from channel to GUID and / or from channel to destination address. For example, the high-side routing table may also separately show the GUID for each channel used (e.g., reserved) and the destination address for each GUID. In other examples, the high-side routing table directly shows the destination address for each channel used. In some examples, the creation of entries in the low-side mapping table and the high-side routing table serves as confirmation that the channel reservation is complete. In other examples, a separate confirmation message is sent to the low video broker to indicate that the channel has been reserved and that transmission of the video stream can begin.

[0076]

[0080] In operation 406, a video stream is received by a raw video broker in a low-reliability environment. In some examples, the raw video broker determines the GUID of the video stream based on the source address of the video stream. For example, the raw video broker accesses a raw mapping table containing GUIDs of different video streams that have a specific source address or are received on a specific port. The raw video broker identifies the GUID of the received video stream based on the address of the video stream or the port on which the video stream was received by the raw video broker.

[0077]

[0081] In operation 408, the raw video broker identifies reserved channels in the received video stream based on the raw-side mapping table. For example, the raw video broker can query the raw-side mapping table using the determined GUID of the video stream to determine the reserved channel corresponding to that GUID.

[0078]

[0082] In operation 410, the low video broker transmits the video stream along the data path defined by the reserved channels of the video stream. For example, the low video broker transmits the video stream so that it flows through a specific guard and a specific port of that guard, as defined by the reserved channels.

[0079]

[0083] In operation 412, the high video broker receives a video stream being transmitted over a reserved channel. The high video broker identifies the reserved channel based on how (or where) the video stream was received. In operation 414, the high video broker queries the high-side routing table using the reserved channel to determine the destination address of the destination device for the video stream. For example, the high video broker may query the high-side routing table using a reserved channel identifier (e.g., channel number), and such a high-side routing table may directly return the destination address. In another example, the high video broker may query the high-side routing table using a reserved channel number, and the GUID of the stream is returned. A second query with the GUID is then performed to return the destination address corresponding to the GUID.

[0080]

[0084] In operation 416, the high video broker transmits the video stream to the destination device having the determined destination address. When the video stream stops or ends, operation 418 removes the channel reservation. The end of the stream may be identified by an end indicator in the video stream packets or datagrams. In other examples, the channel reservation may be removed if the video stream packets have not been received within a threshold period. In some examples, removing a channel reservation may involve removing the corresponding entry from the low-side mapping table and / or high-side routing table. Once the reservation is removed, the channel is free to reserve for another video stream.

[0081]

[0085] Figure 5 is a block diagram showing the physical components (e.g., hardware) of a computing device 500 in which embodiments of this disclosure may be put into practice. The computing device components described below may be suitable for the above-mentioned computing device and system, such as a video broker, guard, landing device, and switching device. In the basic configuration, the computing device 500 includes at least one processing unit 502 and a system memory 504. Depending on the configuration and type of the computing device, the system memory 504 may include volatile storage (e.g., random access memory (RAM)), non-volatile storage (e.g., read-only memory (ROM)), flash memory, or any combination of such memories.

[0082]

[0086] The system memory 504 includes one or more program modules 506 suitable for running a software application 520, such as an operating system 505 and one or more components supported by the system described herein. The operating system 505 may be suitable, for example, for controlling the operation of a computing device 500.

[0083]

[0087] Furthermore, embodiments of this disclosure may be implemented with graphics libraries, other operating systems, or any other application programs, and are not limited to any particular application or system. This basic configuration is shown in Figure 5 by the components within the dashed line 508. The computing device 500 may have additional features or functions. For example, the computing device 500 may also include additional (removable and / or non-removable) data storage devices, such as magnetic disks or optical disks. Such additional storage is shown in Figure 5 by removable storage device 509 and non-removable storage device 510.

[0084]

[0088] As described above, several program modules and data files can be stored in system memory 504. While running on processing unit 502, program module 506 (e.g., application 520) can execute processes including those described herein. Other program modules that may be used according to the embodiments of this disclosure may include email and contact applications, document processing applications, spreadsheet applications, database applications, slide presentation applications, drawing or computer-assisted application programs, etc. For example, application 250 may include a video routing application 525 that performs the operations discussed herein.

[0085]

[0089] Furthermore, embodiments of the present disclosure can be implemented in electrical circuits including discrete electronic elements, packaged or integrated electronic chips including logic gates, circuits utilizing microprocessors, or on a single chip including electronic elements or a microprocessor. For example, embodiments of the present disclosure can be implemented by a system-on-a-chip (SOC), in which each or many of the components shown in Figure 5 may be integrated on a single integrated circuit. Such an SOC device may include one or more processing units, graphics units, communication units, system virtualization units, and various application functions, all of which are integrated (or "burned into") a chip substrate as a single integrated circuit. When operating by an SOC, the functions described herein with respect to the client's ability to switch protocols may be operated by application-specific logic integrated with other components of the computing device 500 on a single integrated circuit (chip). Embodiments of the present disclosure can also be implemented using other techniques capable of performing logical operations such as AND, OR, and NOT, including, for example, mechanical, optical, fluid, and quantum technologies. In addition, embodiments of the present disclosure can be implemented in a general-purpose computer or in any other circuit or system.

[0086]

[0090] The computing device 500 may also have one or more input devices 512, such as a keyboard, mouse, pen, voice or audio input device, touch or swipe input device, etc. It may also include output devices 514, such as a display, speaker, printer, etc. The devices described above are examples, and other devices may be used. The computing device 500 may include one or more communication connections 516 that enable communication with other computing devices 518. Suitable examples of communication connections 516 include radio frequency (RF) transmitters, receivers, and / or transceiver circuits, universal serial buses (USB), parallel and / or serial ports.

[0087]

[0091] As used herein, the term "computer-readable medium" may include computer storage medium. Computer storage medium may include volatile and non-volatile removable and non-removable media implemented by any method or technique for storing information such as computer-readable instructions, data structures, or program modules. System memory 504, removable storage device 509, and non-removable storage device 510 are all examples of computer storage medium (e.g., memory storage). Computer storage medium may include RAM, ROM, electrically erasable ROM (EEPROM), flash memory or other memory technologies, CD-ROM, digital multipurpose disk (DVD) or other optical storage devices, magnetic cassettes, magnetic tapes, magnetic disk storage devices or other magnetic storage devices, or any other manufactured products that can be used to store information and are accessible by the computer 500. Any such computer storage medium may be part of the computer 500. Computer storage medium does not include carrier waves or other propagating or modulated data signals.

[0088]

[0092] Communication media may be embodied by computer-readable instructions, data structures, program modules, or other data within modulated data signals such as carrier waves or other transport mechanisms, and include any information distribution medium. The term “modulated data signal” may refer to a signal in which one or more characteristics are set or modified in a manner that encodes information within the signal. For example, communication media may include wired media such as wired networks or direct wired connections, as well as wireless media such as acoustic, RF, infrared, and other wireless media.

[0089]

[0093] In one embodiment, the technology relates to a system for routing a video stream in a one-way forwarding (OWT) system. The system includes a source video broker in a source computing environment that receives a video stream on an ingress port at an ingress Internet Protocol (IP) address, accesses a mapping table that stores a unique identifier for the video stream based on the video stream's corresponding ingress IP address and port, identifies the unique identifier for the video stream based on the video stream's ingress port and IP address, identifies reserved channels of a plurality of channels that define different data paths through the OWT system based on that unique identifier, and transmits the video stream through the OWT system along the data paths defined by those reserved channels. The system also includes a destination video broker in a destination computing environment protected by the OWT system that receives a video stream on a reserved channel, determines the destination address of the video stream from a routing table that stores corresponding destination addresses of a plurality of different channels based on the reserved channel, and transmits the video stream to a destination device having that destination address.

[0090]

[0094] In one example, the source computing environment is a low-reliability environment, and the destination computing environment is a high-reliability environment. In another example, identifying a reserved channel involves querying a mapping table with a unique identifier for the video stream. In yet another example, the data path of a reserved channel identifies a specific guard and the output port of that guard within the OWT system. In yet another example, identifying a destination address involves querying a routing table with the identifier for the reserved channel and receiving the destination address in response. In yet another example, determining the destination address by the destination video broker involves performing a first query of the routing table on the reserved channel, receiving a unique identifier for the video stream in response to the first query, performing a second query of the routing table with the unique identifier, and receiving the destination address in response to the second query.

[0091]

[0095] In another embodiment, a computer implementation method for routing a video stream in a one-way transmission (OWT) system. The method includes receiving a new channel command for reserving a channel from a plurality of channels for a video stream associated with a unique identifier, the plurality of channels defining different data paths through the OWT system, identifying an unused channel from the plurality of channels, reserving the unused channel for a video stream associated with a unique identifier, receiving the video stream by a source video broker, identifying a unique identifier for the video stream based on the source address of the video stream by the source video broker, identifying a reserved channel for the video stream based on the unique identifier, transmitting the video stream through the OWT system along the reserved channel by the source video broker, receiving the video stream on the reserved channel by a destination video broker in a destination computing environment, determining a destination address for the video stream based on the reserved channel, and transmitting the video stream to a destination device having the destination address by the destination video broker.

[0092]

[0096] In one example, identifying a unique identifier by a source video broker includes accessing a mapping table that stores the unique identifier of a video stream based on the source address of the video stream, and identifying the unique identifier of a video stream based on the source address of the video stream. In another example, reserving a reserved channel includes generating corresponding entries in the source mapping table and the destination routing table. In yet another example, identifying a reserved channel by a source video broker includes querying the source mapping table with the unique identifier of the video stream. In yet another example, determining a destination address by a destination video broker includes querying the destination routing table on the reserved channel. In yet another example, this method further includes removing the channel reservation at the end of the video stream by removing the corresponding entries in the source mapping table and the destination routing table. In yet another example, determining a destination address by a destination video broker includes performing a first query on the destination routing table on the reserved channel, receiving the unique identifier of the video stream in response to the first query, performing a second query on the destination routing table with the unique identifier, and receiving the destination address in response to the second query. In another example, this method further involves generating a confirmation message that the reserved channel is reserved.

[0093]

[0097] In another embodiment, the technology relates to a method for routing video streams in a one-way transport (OWT) system. The method includes receiving a first video stream on a first default channel of the OWT system and a second video stream on a second default channel of the OWT system by a destination video broker in a destination computing environment; determining a first destination address for the first video stream by querying a source routing table with the identifier of the first default channel, the source routing table including an entry indicating at least one of a unique identifier or destination address associated with a reserved channel; determining a second destination address for the second video stream by querying the source routing table with the identifier of the second default channel; transmitting the first video stream to a first destination device having the first destination address; and transmitting the second video stream to a second destination device having the second destination address.

[0094]

[0098] In one example, the first default channel defines a data path through the first guard, and the second default channel defines a data path through the second guard. In another example, the first default channel defines a data path through the first port of the guard, and the second default channel defines a data path through the second port of the guard. In yet another example, the video stream is in Moving Picture Experts Group (MPEG) transport stream (TS) format. In yet another example, this method further includes receiving a new channel command to reserve a channel among several channels for a video stream associated with a unique identifier before receiving the first video stream, the several channels defining different data paths through the OWT system, identifying the first default channel as an unused channel among several channels, and reserving the first default channel for the first video stream. In yet another example, reserving the first default channel includes generating a corresponding entry in the destination routing table.

[0095]

[0099] Aspects of this disclosure are described above, for example, with respect to block diagrams and / or operational diagrams of methods, systems, and computer program products relating to aspects of this disclosure. The functions / actions shown within a block may be performed in a different order than those shown in any flowchart. Depending on the functions / actions involved, for example, two consecutively shown blocks may actually be executed almost simultaneously, or the blocks may be executed in reverse order.

[0096]

[0100] The descriptions and illustrations of one or more embodiments provided herein are not intended in any way to limit or restrict the scope of the disclosure set forth in the claims. The embodiments, examples, and details provided herein are considered sufficient to transfer ownership and enable others to create and use the best form of the disclosure set forth in the claims. The disclosure set forth in the claims should not be construed as being limited to any embodiments, examples, or details provided herein. Various features (both structural and methodological) are intended to be selectively included or omitted to create embodiments having a particular set of features, whether illustrated and illustrated together or separately. Since the descriptions and illustrations provided herein are provided, a person skilled in the art can devise variations, modifications, and alternative embodiments that do not deviate from the broader scope of the disclosure set forth in the claims and that fall within the spirit of a broader embodiment of the general inventive concept embodied herein.

Claims

1. A system for routing video streams in a one-way forwarding (OWT) system, Receive video streams on an Ingress port using an Ingress Internet Protocol (IP) address. Access a mapping table that stores a unique identifier for the video stream based on the corresponding ingress IP address and port of the video stream. Based on the ingress port and IP address of the video stream, a unique identifier for the video stream is identified. Based on the unique identifier, the reserved channels of a plurality of channels that define different data paths through the OWT system are identified. The video stream is transmitted through the OWT system along the data path defined by the reserved channel. Source video broker (104) in source calculation environment (101), The video stream is received on the reserved channel. Based on the reserved channels, the destination address of the video stream is determined from a routing table that stores the corresponding destination addresses of multiple different channels among the multiple channels. The video stream is transmitted to a destination device having the aforementioned destination address. The destination video broker (110) in the destination computing environment (103) protected by the OWT system and A system that includes this.

2. The system according to claim 1, wherein the source computing environment is a low-reliability environment and the destination computing environment is a high-reliability environment.

3. The system according to claim 1, wherein identifying the reserved channel includes querying the mapping table with the unique identifier of the video stream.

4. The system according to claim 1, wherein the data path of the reserved channel identifies a specific guard and the output port of the specific guard within the OWT system.

5. The system according to claim 1, wherein identifying the destination address includes receiving the destination address in response to a query of the routing table by the identifier of the reserved channel.

6. The destination address is determined by the destination video broker. Execute the first query on the routing table on the reserved channel. Receiving the unique identifier of the video stream in response to the first query, Execute a second query on the routing table using the aforementioned unique identifier, and Receiving the destination address in response to the second query. The system according to claim 1, including the following:

7. A computer implementation method for routing a video stream in a one-way forwarding (OWT) system, Receiving a new channel command (402) to reserve a channel from among several channels for a video stream associated with a unique identifier, wherein the several channels define different data paths through the OWT system, Identifying unused channels among the aforementioned multiple channels, Reserving the unused channel for the video stream associated with the unique identifier (404), The source video broker receives the video stream (406), The source video broker identifies a unique identifier for the video stream based on the source address of the video stream. Identifying the reserved channel of the video stream based on the unique identifier (408), The source video broker transmits the video stream through the OWT system along the reserved channel (410), The destination video broker in the destination calculation environment receives the video stream on the reserved channel (412), Determining the destination address of the video stream based on the reserved channel (414), and The destination video broker transmits the video stream to the destination device having the destination address (416) Methods that include...

8. The source video broker identifies the unique identifier, Accessing a mapping table that stores a unique identifier for a video stream based on the source address of the video stream, and Identifying the unique identifier of the video stream based on the source address of the video stream. The method according to claim 7, including the method described in claim 7.

9. The method according to claim 7, wherein reserving the reserved channel includes generating corresponding entries in the source mapping table and the destination routing table.

10. The method according to claim 9, wherein identifying the reserved channel by the source video broker includes querying the source mapping table with the unique identifier of the video stream.

11. The method according to claim 9, wherein determining the destination address by the destination video broker includes querying the destination routing table on the reserved channel.

12. The method according to claim 9, further comprising removing the reservation for the channel at the end of the video stream by removing the corresponding entries in the source mapping table and the destination routing table.

13. The destination address is determined by the destination video broker. Execute the first query on the destination routing table on the reserved channel. Receiving the unique identifier of the video stream in response to the first query, Execute a second query on the destination routing table using the aforementioned unique identifier, and Receiving the destination address in response to the second query. The method according to claim 9, including the method described in claim 9.

14. The method according to claim 13, further comprising generating a confirmation message that the reserved channel is reserved.

15. A method for routing a video stream in a one-way forwarding (OWT) system, The destination video broker in the destination computing environment receives the first video stream on the first default channel of the OWT system and the second video stream on the second default channel of the OWT system (412). Determining a first destination address for the first video stream by querying a source routing table with the identifier of the first default channel (414), wherein the source routing table includes an entry indicating at least one of a unique identifier or destination address associated with a reserved channel (414), The second destination address of the second video stream is determined by querying the source routing table with the identifier of the second default channel (414). Transmitting the first video stream to a first destination device having the first destination address (416), and Transmitting the second video stream to a second destination device having the second destination address (416) Methods that include...

Images