Routing of full dynamic video streams (fmv) in unidirectional transmission systems using out-of-band routing tables

Abstract

Examples of the present disclosure describe systems and methods relating to full dynamic video (FMV) routing in a one-way transport (OWT) system. The technique reserves a specific channel for video stream transmission, and then transmits a video stream from a low-trust computing environment to a high-trust computing environment along a data path defined by the channel. When a video stream is received at a highly trusted end, a channel on which the video stream is received is determined and used to query a routing table that returns a destination address of a destination device to which the video stream is to be transmitted. The video stream is then delivered to a destination device having a corresponding address.

Description

BACKGROUND

[0001] In data transmission and communication systems, communication is typically performed in a bidirectional manner. For example, two devices communicating with each other exchange data in both directions. This capability allows for confirmation or acknowledgement that data has been properly received and processed. In the event that data is not properly received or processed, for example due to packet loss or data corruption, the receiving device is able to request retransmission of the data. In systems that only implement unidirectional communication, there is no such confirmation or request for retransmission of data available.

[0002] With these and other general considerations in mind, aspects disclosed herein have been made. Also, although relatively specific problems can be described, it should be understood that these examples should not be limited to resolving the specific problems identified in the background or other contexts. SUMMARY

[0003] Examples of the present disclosure describe systems and methods involving full-motion video (FMV) routing in a unidirectional transmission (OWT) system. The OWT system includes components that limit the flow of data through the system in a single direction while providing additional reliability enhancements to help ensure that video streams are properly processed and tolerate faults in the devices of the system. For example, the system can include a transmitting computing device that has an optical transmitter limited to only transmitting functionality. The present technology reserves a specific channel for video stream transmission and then transmits the video stream along a data path defined by the channel from a low-trust computing environment to a high-trust computing environment. When the video stream is received at the high-trust termination, the channel on which the video stream was received is determined and used to query a routing table, which returns a destination address of a destination device to which the video stream is to be transmitted. The video stream is then transmitted to the destination device having the corresponding address. As a result, the video stream can still be properly routed through the OWT and into the high-trust computing environment even in the case where the source device in the low-trust computing environment does not know the destination address.

[0004] This Summary is provided to introduce some concepts in a simplified form that are further described below in the detailed description. This Summary is not intended to identify key or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter. Additional aspects, features, and / or advantages of examples will be set forth in the description that follows, and in part will be apparent to those with skill in the relevant art, and will be learned from the description that follows. Examples may BRIEF DESCRIPTION OF DRAWINGS

[0005] Examples are described with reference to the following figures.

[0006] Figure 1 An example unidirectional transmission (OWT) system for full-motion video routing is shown.

[0007] Figure 2Example data streams of multiple video streams are shown through an example OWT system.

[0008] Figure 3 An example fault-tolerant video stream kernel in a unidirectional transmission system is shown.

[0009] Figure 4 An example method for fully dynamic video routing using out-of-band routing tables is shown.

[0010] Figure 5 This is a block diagram illustrating example physical components of a computing device used to practice various aspects of the present disclosure. Detailed Implementation

[0011] A One-Way Transmission (OWT) system refers to a computing system that uses one or more data diodes to ensure that data can only be transmitted in one direction through the corresponding computing device of the computing system. In this example, the data diodes ensure unidirectional data packet transmission through the implementation of hardware and / or software components such as a network interface card (NIC) that only transmits data.

[0012] OWT systems can be used to protect networks or endpoints from outbound data transmissions, malicious inbound data transmissions (e.g., viruses and malware), and network attacks. As an example, an OWT system facilitates data transmission between endpoints in a low-trust computing environment (such as the public internet or other high-threat environments) and endpoints in a high-trust computing environment (or a more secure computing environment relative to the low-trust computing environment). In such an example, an OWT system spans or includes multiple computing environments separated by one or more boundaries between low-trust and high-trust computing environments.

[0013] In the examples, a high-trust environment can be a system or network where devices, applications, and users are considered trustworthy, and security measures are implemented to establish and maintain trust. In this type of environment, the devices and / or parties involved (e.g., devices, software, and users) are typically authenticated, authorized, and / or comply with established security policies and best practices. High-trust environments typically have strict access controls, encryption, and monitoring to ensure trust is maintained and to minimize the risk of unauthorized access, data corruption, or other security incidents. Based on the security technologies implemented by the high-trust environment (e.g., unique encryption keys, secrets, or other cryptographic techniques), devices within the high-trust environment can be authorized to access or be accessed by other devices. For example, based on a high-trust environment (or its devices) included in a permitted list (e.g., a list of approved devices and / or computing environments), communications transmitted by a high-trust environment can be considered trustworthy by other computing environments or devices. Alternatively, communications transmitted by a high-trust environment can be considered trustworthy based on passwords or credentials provided with the communications. In some examples, devices in a high-trust environment do not require authentication to access or be accessed by other devices. High-trust environments typically do not expose security technologies implemented by the high-trust environment to other computing environments, which may be considered low-trust or untrusted environments by the high-trust environment.

[0014] In contrast, a low-trust or untrusted environment can be a high-risk system or network where devices, applications, and / or users are not implicitly trusted or where unauthorized access or malicious activity exists. This type of environment may have limited or no security measures, or it may be an environment connecting a large number of external or unmanaged devices. Alternatively or additionally, a low-trust or untrusted environment refers to an environment in which devices are not considered secure or trusted by other devices inside and / or outside the low-trust or untrusted environment. Because the security technologies implemented by the high-trust environment are not exposed to the low-trust or untrusted environment, the low-trust or untrusted environment may be unable to access or communicate with the high-trust environment, and may not perform various authorization and / or authentication steps that are not required to be performed by devices in the high-trust environment.

[0015] Because of the unidirectional data transmission in an OWT system, it's impossible to confirm whether data sent over a unidirectional transmission line has been received and / or correctly processed by the receiving device. In contrast, in a bidirectional system, a communication protocol such as Transmission Control Protocol (TCP) can be used, where acknowledgments can be sent back to the sending device. For example, using TCP, when a connection is established between two devices, they exchange a series of messages to synchronize and establish connection parameters. Then, when the sending device sends data, the receiving device sends an acknowledgment (ACK) message back to the sending device to confirm that it has received the data. If the sending device does not receive an ACK within a certain amount of time, it will retransmit the data. For an OWT system, such ACK messages are impossible because communication cannot be sent from the receiving device back to the sending device. Instead, a unidirectional communication protocol must be used for communication, such as User Datagram Protocol (UDP). As a result, a robust system is required to help ensure that data sent from the sending device is actually received and correctly processed by the receiving device. Without such a system, the reliability of the system would be significantly reduced.

[0016] Furthermore, due to the OWT scenario and the separation between low-trust and high-trust environments, source devices in the low-trust environment are unaware of the final destination. For example, when wanting to send a video stream from a low-trust end to a specific destination in the high-trust end, the low-trust end device typically doesn't know the actual address of the destination device because the IP address is confidential or protected and unaffected by devices in the low-trust end. As a result, only devices within the high-trust environment can access the destination address, and routing data from the low-trust end to the high-trust end becomes particularly challenging because routing is essentially blind. For example, the video source device knows the address of another intermediate device on the low-trust end, but the video source doesn't know the address of the final destination. Additionally, intermediate devices may also be unaware of the final destination address. These challenges are exacerbated for live video streams without discrete packet lengths (e.g., unknown end times), where routing must be managed continuously throughout the unknown duration of the video stream.

[0017] This technology provides a solution to the aforementioned problems by reserving specific video channels and then routing video streams based on those specific channels on which they are received. For example, when a new video stream is to be established, a channel is requested from the OWT system, providing a globally unique identifier (GUID) associated with the video stream. A channel is then reserved for the specific video stream and the GUID. When the video stream is transmitted from the source computing environment to the destination environment, devices in the destination environment monitor the reserved channel for the video stream. The devices determine the destination address of the video stream based on the GUID. The video stream is then transmitted to the destination device with the corresponding source address. As a result, even if the source device does not know the destination address, the video stream can still be correctly routed through the OWT system and then routed to the high-trust computing environment.

[0018] Figure 1 An example OWT system 100 for fully dynamic video routing is shown. As illustrated, system 100 is a combination of interdependent components that interact to form an integrated whole. The components of system 100 can be hardware or software components (e.g., application programming interfaces (APIs), modules, runtime libraries) 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 devices or computing systems.

[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 in a cloud computing environment or another type of distributed computing environment and conform 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.

[0020] Although Figure 1 It is described as a specific combination of computing environments and devices, but the size and structure of the devices and computing environments described herein can vary, and can include more than [other components]. Figure 1 The components described herein may include more or fewer components. Furthermore, although the examples presented herein are described in the context of data transfer between OWT systems and low-trust computing environments versus high-trust computing environments, these examples can also be applied to other types of data transfer between computing environments of various (or similar) types and security levels. For example, the first computing environment 101 may also be referred to as the source computing environment, and the second computing environment 103 may be referred to as the destination computing environment.

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

[0022] The first computing environment 101 may represent a low-trust computing environment, wherein devices executing within computing environment 101 are not trusted by devices executing within the second computing environment 103. In these examples, 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), while the second computing environment 103 is located in one or more other physical locations. Alternatively, in other examples, computing environments 101 and 103 are both located in the same physical location.

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

[0024] Then, the low-side video agent 104 receives the video stream. The low-side video agent 104 is a computer device, such as a server, that processes and transmits the received video stream. The transmission of the received video stream is based on a specific GUID used for the specific video stream received. For example, the received video stream is transmitted through a specific channel based on the specific GUID used for the video stream. Information about the channel through which the video stream is transmitted based on the GUID can be stored in a low-side FMV mapping table 114, which includes data from users (e.g., clients) or administrators in the second environment 103. For example, when a new source-to-destination (e.g., low-to-high) video stream is requested, a virtual machine is provided to receive and process the new video stream on a specific IP address and port, which may be referred to as the ingress IP address and / or ingress port. The GUID, ingress IP address, and port for the new video stream can be provided in the low-side FMV mapping table 114. The data in the low-side FMV mapping table 114 indicates a specific GUID for each video stream to be received by the low-side video agent 104, also referred to herein as a data stream ID. For example, a specific GUID can be assigned to each ingress IP address and port for receiving a specific data stream. The low-frequency video proxy 104 then monitors the video feeds on the assigned port or from the assigned IP address.

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

[0026] Different channels in an OWT system can include specific paths through which data propagates through the system. For example, protection device 108 may have a fixed group of video channels, and each graphics processing unit (GPU) of protection device 108 may have approximately 10 video channels. A given video channel may have a static input port and a static destination or output port. A static input port receives a specific video stream, and a specific video channel may continue processing the video stream for the duration of the stream. The static destination of all video channels of protection device 108 may be a specific port of high video proxy 110. Thus, in some examples, each channel is defined by (1) a specific protection for receiving / transmitting video streams and (2) a specific output port of the protection. For example, channel 1 may be defined as protection device 1 and port 1. Channel 2 may be defined as protection device 1 and port 2. Channel 11 may be defined as protection 2 and port 2 of protection device 2. Each of these channels may be predefined. The number of channels continues to increase as additional protections and devices are implemented.

[0027] When orchestrator 105 receives a new channel command, it queries a list of predefined channels to determine whether a channel is open or unused. It then creates or edits entries in the high-side FMV routing table 116, associating the channel with the GUID provided in the new channel command. Orchestrator 105 can then transmit an acknowledgment message confirming that a channel has been reserved and video streaming can proceed. In this example, the acknowledgment message is transmitted to the second computing environment 103, where it is received by the source video agent 104. Appropriate entries associating reserved channels with specific GUIDs can also be generated in the low-side FMV mapping table 114.

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

[0029] New channel requests are sent separately from the video stream and before the video stream, and similarly, channels are reserved for the video stream before it is received. Thus, the new channel command and channel reservation process can be considered out-of-band communication and procedures.

[0030] Once the channel reservation is complete, the source video proxy 104 receives the corresponding video stream. Upon receiving the video stream, the source video proxy 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 proxy 104 for the received video stream. Based on the GUID, the reserved channel for the video stream is also identified from the low-side FMV mapping table 114. The source video proxy 104 then transmits the video stream on the reserved channel. For example, the source video proxy 104 causes the video stream to propagate along the data path defined by the reserved channel through the fault-tolerant OWT core 106 and the protection device 108.

[0031] Protection device 108 protects the second computing environment 103 from data entering the second computing environment 103 from the first computing environment 101. Protection device 108 performs alterations and / or checks on the video stream. For example, in some examples, protection device 108 transcodes the video stream. Alternatively or additionally, protection device 108 performs security checks or policy enforcement on the video stream to remove malicious data or any other type of data, according to policies set by the administrator of the second computing environment 103. As an example, protection device 108 enforces data patterns, such as enforcing patterns for specific video stream formats. If the video stream meets the criteria proposed by protection device 108, protection device 108 also transmits the video stream from the port defined by the reserved channel to high video agent 110. Therefore, protection device 108 itself does not need to know or determine the final destination of the video stream in the second environment 103. Instead, protection device 108 simply outputs the video stream on the port according to the reserved channel, where high video agent 110 receives the video stream from the output port of protection device 108.

[0032] When the high-video proxy 110 receives a video stream, it determines the channel on which the video stream is received. Based on the specific channel, the high-video proxy 110 identifies the GUID of the video stream and the destination address (e.g., IP address or port) of the video stream in the second computing environment 103 of the video stream's destination devices 112. For example, the high-video proxy 110 performs a lookup operation or query on the high-side FMV routing table 116 with reserved channels, which returns one or more destination addresses and / or GUIDs of the video stream transmitted on the reserved channels.

[0033] Then, the high-resolution video agent 110 transmits the video stream to the identified destination(s) and destination(s) 112. Because the high-resolution video agent 110 and the destination(s) 112 are in the same second environment 103, bidirectional communication such as TCP can be used for the transmission of the video stream from the high-resolution video agent 110. The destination(s) 112 then displays, stores, and / or processes the live video stream for the duration of the video stream.

[0034] Figure 2 Example data streams of multiple video streams are shown through example OWT system 200. Example system 200 may be substantially the same as or similar to system 100. However, in system 200, three protective devices 108A to 108C are shown.

[0035] In the illustrated data stream, source video agent 104 receives and processes three separate video streams. These 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 sent by source video agent 104, a new channel command is sent for each video stream, and a different channel is reserved for each. In the example shown, 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 a predefined data path flowing through the first protection device 108A. Channel 2 is a predefined data path flowing through the second protection device 108B. Channel 3 is a predefined data path flowing through the third protection device 108C.

[0036] When the source video agent 104 receives VS1, it queries the low-side FMV mapping table 114 to determine that channel 1 is reserved for VS1. Then, the source video agent 104 causes VS1 to be transmitted along the data path defined by channel 1 (e.g., via the fault-tolerant OWT core 106 and the first protection device 108A). Similar operations are performed on VS2 and VS3, causing them to be transmitted along the data paths defined by channels 2 and 3, respectively.

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

[0038] In the depicted example, high-side video proxy 110 queries high-side FMV routing table 116 to determine that channel 1 corresponds to the destination address of the first destination device 112A. Therefore, high-side video proxy 110 transmits VS1 to the first destination device 112A. High-side video proxy 110 also queries high-side FMV routing table 116 to determine that channel 2 corresponds to the destination address of the second destination device 112B. Therefore, high-side video proxy 110 transmits VS2 to the second destination device 112B. High-side video proxy 110 also queries high-side FMV routing table 116 to determine that channel 3 corresponds to the destination address of the third destination device 112E. Therefore, high-side video proxy 110 transmits VS3 to the third destination device 112C. As a result, although the source video proxy 104 does not know the final destination addresses of the various streams, the system of this technique is able to correctly route video streams to their destinations. Furthermore, this blind routing is achieved without modifying the video streams themselves or the corresponding datagrams and packets.

[0039] A reservation for a specific channel can be removed when a video stream ends or when there is a delay exceeding a threshold amount of time in the packet delivery of the data stream. In some examples, removing a reservation involves deleting the corresponding entry for the reserved channel from 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 incorrect forwarding of received video streams to the wrong destination device. For example, when VS1 ends (which can be detected by an end indicator in the packet identifying the video stream), the reservation for channel 1 is removed. If a new video stream is subsequently received on channel 1 without reserving channel 1 for the new video stream, the high video agent 110 will discard (e.g., delete) or store the new video stream instead of transmitting it to the first destination device 112A.

[0040] Figure 3 An example fault-tolerant video stream core 300 in a one-way transmission system is shown. In the example shown, core 300 includes... Figure 1 The example system is a fault-tolerant OWT core 106 and a protection device 108 of system 100.

[0041] Figure 3 Again, the first computing environment 301 and the second computing environment 303 are indicated. In the example shown, the first computing environment 301 includes a computing device 308. The computing device 308 may be referred to herein as a low-side computing device 308 or a transmitting device 308. The low-side computing device 308 receives data from a low-side agent (…). Figure 3(Not shown in the image) Receives video stream 310. The low-side computing device 308 can serialize the video stream 310 by dividing it into one or more data blocks using a file segmentation service or utility, which can be implemented locally on the computing device 308 or remotely accessed by the computing device 308.

[0042] The segmented data of video stream 310 is then 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 near computing device 308 (e.g., in the same building or room). For example, computing devices 312, 314, and 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 in different racks of the first data rack. In such examples, computing devices 308 and 312, 314 may be directly connected via point-to-point cables, which may be optical, as discussed further herein.

[0043] In some examples, computing devices 312 and 314 are also physically separated from each other to help ensure reliability and redundancy. For example, computing devices 312 and 314 may be in different server racks, different rooms, or different buildings that rely on different power supplies. Therefore, if computing device 312 loses power, the second computing device 314 can still maintain power. In other examples, computing devices 312 and 314 are located away from computing device 308 (e.g., in different buildings or rooms).

[0044] Computing devices 312 and 314 receive video streams transmitted from the lower-side computing device 308. Therefore, in some examples, computing device 312 may be referred to herein as a first receiving device 312, and computing device 314 may be referred to herein as a second receiving device 314. Receiving devices 312 and 314 can also operate as protection devices, and computing devices 312 and 314 may also be referred to as a first protection device 312 and a second protection device 314, or cross-domain protection devices 312 and 314.

[0045] Returning to data transmission between the low-side computing device 308 and the protective devices 312, 314, unidirectional data transmission from the low-side computing device 308 to the protective devices 312, 314 can be optically achieved. The use of optical transmission increases the additional speed, reliability, and / or security of data transmission. In the example shown, the low-side computing device 308 includes an optical transmitter 309 that converts segmented data of the video stream 310 into optical signals that are transmitted to 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.

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

[0047] Optical transmitter 309 may be part of a transmission-only NIC or other circuit board that includes transmission-only capabilities. For example, the circuit board may not have the capability to receive optical data. In other examples, if the circuit board does include an optical receiver, there is no fiber optic cable from any of the shielding devices 312, 314 connected to the receiver, so the optical receiver cannot receive data. For example, the transmission-only NIC transmits data to an endpoint, but cannot receive data from the endpoint due to a physical cut-off of the receive pin on the transmission-only NIC's network controller chip. In some examples, the transmission-only NIC also includes firmware that sets the link state of the transmission-only NIC to always be "on" (e.g., enabled and / or active). In other examples, a transmission-only circuit is formed by attaching a splitter cable (e.g., a Y-splitter cable), where the transmission signal is split across two cables, and one cable is routed back to the optical receiver of the transmitter circuit. This establishes a layer 1 link state and allows the circuit to sense a return data path, even if no actual return data path exists. In other examples, a field-programmable gate array (FPGA) or similar device may be configured to restrict the data flow to unidirectional only (e.g., transmission-only). In cases where physical components (rather than software-defined constraints) require unidirectional communication, unidirectional communication is considered physically enforced.

[0048] The optical signal generated by the optical transmitter 309 is then split by the beam splitter 317. The beam splitter 317 splits the optical signal into multiple optical signals (e.g., splitting the light transmitted through the first optical fiber 311). In the described example, the optical signal is split into two divided optical signals. One of the divided optical signals is transmitted to the first receiving optical fiber 319, while the other divided optical signal is transmitted to the second receiving optical fiber 321. Each of the divided optical signals replicates the original optical signal and therefore includes sample data as part of the original optical signal. Although the optical signal is split into two optical signals in this example, in different examples the light can be split into additional signals.

[0049] In some examples, beam splitter 317 is a passive beam splitter that requires no electrical power. For example, when light enters beam splitter 317 from first fiber 311, the light is split into first receiving fiber 319 and second receiving fiber 321 without requiring additional power. Passive beam splitter 317 utilizes the reflective and / or refractive properties of its material to separate light, for example by using two glass prisms, a half-silvered mirror, a dichroic mirror prism, or other suitable designs for beam splitting, with the two glass prisms adhered to each other or otherwise connected to create a partially reflective surface.

[0050] Because the passive beam splitter 317 requires no power to operate, additional reliability is introduced into the system by utilizing it. However, in other examples, an active or motorized beam splitter 317 may be used. In some examples, the beam splitter 317 is located within a first computing environment 301 or a second computing environment 303. For example, the beam splitter 317 may be part of a low-side computing device 308 and / or a part of an optical transmitter 309. In other examples, the beam splitter 317 is located in a second computing environment 303. For example, the beam splitter 317 may be integrated into a protective device 312, a second protective device 314, and / or another device in the second computing environment 303.

[0051] Although beam splitter 317 is primarily discussed herein as a passive beam splitter, it may include other devices for separating and / or replicating optical signals, and in some examples, it may also be powered. For example, beam splitter 317 may include a switch with a Switched Port Analyzer (SPAN) port. The SPAN port creates a copy or replica of data that can then be sent to another destination. Therefore, in some examples, the SPAN port may also be referred to as a mirror port. The copy is created by monitoring the source port and replicating the data received on the source port. Beam splitter 317 may also be in the form of a Test Access Point (TAP). A TAP is a passive hardware device that separates or replicates data via a beam splitter or passive optical coupler that splits an optical signal into two separate paths.

[0052] Then, the first protective device 312 and the second protective device 314 receive the segmented optical signals in parallel. 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 protective device 312 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 protective device 314 coupled to the second receiving optical fiber 321. The optical receivers 313 and 315 convert the optical signals into electrical data signals, which 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 protective device 312 and the second protective device 314 as discussed herein. In effect, the copied video stream is thus received by the protective devices 312 and 314.

[0053] If the first protective device 312 determines that the video stream 310 meets the requirements of the second computing environment 303 (as described above), then the first protective device 312 transcodes the video stream and sends it to the first landing device 318. Similarly, if the second protective device 314 determines that the video stream meets the requirements of the second computing environment, then the second protective device 314 transmits the video stream and transcodes it to the second landing device 320. Therefore, if both protective devices 312 and 314 are functioning properly and transmitting the video stream 310, then the landing devices 318 and 320 receive a copy of the video stream 310.

[0054] Because the video stream 310 transmitted from the first computing environment 301 to the second computing environment 303 is unidirectional, there is no acknowledgment or request to retransmit the video stream (or a portion thereof) from the second computing environment 303 back to the first computing environment 301. For example, if the first protection device 312 or the first landing device 318 were to cease operation (e.g., system crash, power failure), the low-side computing device 308 would not be able to determine that the device was no longer functioning correctly. To help ensure that the video stream received by the second computing environment 303 is processed and processed with high fidelity, the second protection device 314 and the second landing device 320 provide data redundancy to the first protection device 312 and the first landing device 318 for the video stream 310 transmitted from the first computing environment 301 to the second computing environment 303. Therefore, even if one of the protection devices 312 or the second protection device 314 (and / or the first landing device 318 or the second landing device 320) becomes inoperable, the other device can still process the video stream 310.

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

[0056] Performance data 316 indicates the performance and / or status of the specific device sending it and / or data about 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 about the corresponding protection. For example, performance data 316 from the first landing device 318 may also indicate operational status data of the first protection device 312. Performance data 316 may also include operational status data of the second protection device 314. Therefore, based on status data 316, each of the first landing device 318 and the second landing device 320 can determine whether the other device is functioning correctly.

[0057] The first landing device 318 and / or the second landing device 320 use performance data 316 to change their operating state and determine which of the first landing device 318 or the second landing device 320 is the source of the video stream 310 provided to the advanced frequency proxy 325.

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

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

[0060] For MPEG-TS format video streams, the continuity counter is a 4-bit field in the header of each Transport Stream Packet (TSP). The counter increments by 1 for each consecutive packet carrying a payload belonging to the same Packetized Stream Basic (PES), where PES represents 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 then 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 is being received. The first set of 16 counts / packets can then be distinguished from the second set of 16 counts / packets (and other subsequent sets).

[0061] As some additional details, when the video stream 310 is initially encoded in the first computing environment 301, the video stream 310 is broken down into smaller blocks 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 sequence of packets within the PES. As packets are transmitted, the continuity counter in the TSP header is incremented for each consecutive packet belonging to the same PES.

[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 in the expected order, the first landing device 318 and the second landing device 320 can assume that the packets have arrived in the correct order without loss or duplication. If the continuity counter value is out of order, the first landing device 318 and the second landing device 320 can detect packet loss, duplication, or reordering.

[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 for each packet processed by the first landing device 318 and / or the second landing device 320 is included in the performance data 316. For example, when the first landing device 318 processes a particular packet, the performance data 316 may indicate to the continuity counter value of the packet that the packet was processed by the first landing device 318.

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

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

[0066] In such an example, the first landing device 318 remains in its master device operational state until the second landing device 320 ceases to function or ceases to function correctly. The criteria used to determine whether the first landing device 318 is functioning correctly can be based on performance metrics of the first landing device 318, which can be represented in performance data 316. For example, health data and / or transmission information can be compared to one or more thresholds to determine whether the first landing device 318 is functioning correctly or within acceptable limits. If performance data 316 is not received (e.g., due to the first landing device 318 going offline), performance data 316 can be considered outside the thresholds and thus indicate a non-functionality of the first protective device 312. Such a determination can be made by the second landing device 320 based on performance data 316 received from the first landing device 318. Additionally or alternatively, 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 correctly.

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

[0068] When the second landing device 320 operates as the primary device, it can continue to transmit performance data 316 to the first landing device 318. In examples where the first landing device 318 is still operating (but with degraded performance), it can also continue to transmit performance data 316 to the second landing device 320. In some examples, the second landing device 320 continues to operate as the primary device even when the first landing device 318 regains its correct or acceptable performance (as indicated by performance data 316). In these examples, the first landing device 318 can switch back to being the primary device when performance data 316 indicates that the second landing device 320 is no longer functioning correctly. The determination that the second landing device 320 is not functioning correctly can be similar to the determination of the first landing device 318's normal operation described above. For example, the first landing device 318 can compare the performance data 316 from the second landing device 320 with one or more thresholds to determine whether the second landing device 320 is functioning correctly.

[0069] In other examples, the second landing device 320 may switch back to a secondary device upon detecting that the first landing device 318 has regained functionality. The first landing device 318 then resumes its operation as the primary device. For example, based on performance data 316, the second landing device 320 may determine that the first landing device 318 has regained the correct functionality. The second landing device 320 may then transmit a message (e.g., as part of performance data 316) instructing the first landing device 318 to resume operation as the primary device, and the second landing device 320 switches its operation to a secondary device.

[0070] Switching between operational states can occur rapidly, and in some examples, this switching can happen in less than 100 milliseconds (ms). In some examples, the switching occurs on a packet-by-packet basis. For example, if the second landing device 320 operates 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 has not processed the specific packet, then the second landing device 320 transmits the specific packet. The transmission of the specific packet can then be indicated in the performance data 316. The first landing device 318 can remain in an operational state as the primary device for subsequent packets, or the second landing device 320 can switch to become the primary device for subsequent packets until another packet is processed by one landing device instead of the other.

[0071] In some examples, landing devices 318 and 320 do not change their operational state. Instead, both landing devices 318 and 320 can transmit a copied video stream to switching device 323. Performance data 316 from each landing device 318 and 320 can also be provided to switching device 323. Switching device 323 then switches between the primary video stream (e.g., the video stream from the first landing device 318) and the secondary enhanced video stream (e.g., the video stream from the second landing device 320), and provides a single video stream to high video proxy 325.

[0072] Switching device 323 effectively uses the copied video stream 310 from first landing device 318 and second landing device 320 as the primary and secondary video streams. The primary video stream is provided to the high video proxy until an interruption of the primary video stream is detected. When an interruption is detected, the secondary stream is then transmitted to the high video proxy 325.

[0073] Interruptions in the primary video stream can be based on the video stream and / or a continuity counter from performance data 316. For example, when expected packets of video stream 310 are not received as part of the primary video stream, switching device 323 can quickly switch to the secondary video stream and provide the secondary video stream to high video agent 325. Switching device 323 can continue to provide the secondary video stream to high video agent 325 until switching device 323 detects an interruption in the secondary video stream. When an interruption is detected in the secondary video stream, switching device 323 then switches back to the primary video stream. Because switching device 323 receives both the primary and secondary video streams simultaneously, switching device 323 switches to the video stream with the fewest interruptions or typically the least frequency of dropped packets. The switching between the primary and secondary video streams can be performed quickly (e.g., 100 ms or less). For example, in some examples, the switching occurs on a per-packet basis.

[0074] Switching between the primary and secondary video streams can also 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 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 encountered any interruption.

[0075] In such an example, the predefined channel discussed herein can still be identified by the unique data path of the IP address, port, and / or device within system 300. Therefore, the high-resolution video proxy 110 can still identify the video stream based on the channel on which the video stream is received.

[0076] Although Figure 3 The OWT system 300 shown is configured for use Figure 1 and 2The first fault-tolerant OWT core 106, however, the OWT system 300 can be effectively inverted to allow data to be output and used for the second OWT core 107. In other examples, a simpler OWT system can be used for the second OWT core 107 because the fidelity of the data output from the second computing environment 103 may be less important than the fidelity of the data entering the second computing environment 103 (e.g., a video stream).

[0077] Figure 4 An example method 400 for fully dynamic video routing is shown. Method 400 can be executed by one or more of the devices described above, for example... Figures 1 to 3 One or more devices are shown.

[0078] In Operation 402, a new channel command or request is generated and / or received. The new channel command includes a GUID for the video stream to be received by the low-video agent. In some examples, the low-video agent generates the new channel command, or another device, such as an orchestrator, generates or receives the new channel command. For example, a new channel command can be sent on the control plane of the network in the OWT system discussed herein.

[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 multiple predefined channels to identify open or currently unused channels. The identified channel is then reserved. Channel reservation may also include generating corresponding entries in the low-side mapping table and the high-side routing table. Entries in the low-side mapping table indicate the specific reserved channel corresponding to the GUID in the new channel command. Entries in the high-side routing table include a channel-to-GUID mapping and / or a channel-to-destination address mapping. For example, the high-side routing table may indicate the GUID for each used (e.g., reserved) channel and also indicate the destination address for each GUID. In other examples, the high-side routing table directly indicates the destination address for each used channel. In some examples, the creation of entries in the low-side mapping table and the high-side routing table serves as confirmation that channel reservation has been completed. In other examples, a separate confirmation message is transmitted to the low-side video agent to indicate that the channel has been reserved and that video stream transmission can begin.

[0080] In Operation 406, a low-trust video agent receives video streams. In some examples, the low-side video agent determines the GUID of the video stream based on its source address. For instance, the low-side video agent accesses a low-side mapping table that includes GUIDs for different video streams with a specific source address or received on a specific port. The low-side video agent identifies the GUID of the received video stream based on the video stream's address or the port on which the low-side video agent receives the video stream.

[0081] In operation 408, the low-side video agent identifies the reserved channel for the received video stream based on the low-side mapping table. For example, the low-side video agent can query the low-side mapping table for the determined GUID for the video stream to determine the corresponding reserved channel for the GUID.

[0082] In operation 410, the low-level video agent transmits the video stream along a data path defined by a reserved channel for the video stream. For example, the low-level video agent transmits the video stream so that the video stream flows through a specific port with specific protection defined by the reserved channel.

[0083] In operation 412, the high-video agent receives the video stream that has already been transmitted via a reserved channel. The high-video agent identifies the reserved channel based on how (or from where) the video stream was received. In operation 414, the high-video agent uses the reserved channel to query the high-side routing table to determine the destination addresses of the destination devices (multiples) for the video stream. For example, the high-video agent may query the high-side routing table for the reserved channel identifier (e.g., channel number), which may directly return the destination address. In other examples, the high-video agent queries the high-side routing table for the reserved channel number and returns the GUID of the stream. A second query with the GUID is then performed to return the destination address corresponding to the GUID.

[0084] In operation 416, the high-level video agent transmits the video stream to the destination device with the determined destination address. When the video stream stops or ends, the channel reservation is then removed in operation 418. The end-of-stream indication can be performed via an end indicator in the video stream packets or datagrams. In other examples, the channel reservation can be removed if no video stream packets are received within a threshold time period. In some examples, removing a channel reservation may include removing the corresponding entry from the low-side mapping table and / or the high-side routing table. Once the reservation is removed, the channel is reserved for other video streams.

[0085] Figure 5 This is a block diagram illustrating the physical components (e.g., hardware) of a computing device 500 that can implement various aspects of this disclosure. The computing device components described below are applicable to the aforementioned computing devices and systems, such as video agents, protection devices, landing devices, switching devices, etc. In a 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 memory (e.g., random access memory (RAM)), non-volatile memory (e.g., read-only memory (ROM)), flash memory, or any combination of these memories.

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

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

[0088] As described above, multiple program modules and data files can be stored in system memory 504. When executed on processing unit 502, program module 506 (e.g., application program 520) can perform processes including the aspects described herein. Other program modules that can be used according to the aspects of this disclosure may include email and contact applications, word processing applications, spreadsheet applications, database applications, slideshow applications, drawing or computer-aided applications, etc. For example, application program 520 may include video routing application 525 that performs the operations discussed herein.

[0089] Furthermore, embodiments of this disclosure can be implemented on circuits including discrete electronic components, packaged or integrated electronic chips containing logic gates, circuits utilizing microprocessors, or circuits containing electronic components or microprocessors on a single chip. For example, embodiments of this disclosure can be implemented via a system-on-a-chip (SOC), wherein... Figure 5 Each or more components shown can be integrated onto a single integrated circuit. Such a SoC device may include one or more processing units, graphics units, communication units, system virtualization units, and various application functions, all integrated (or “programmed”) onto a chip substrate as a single integrated circuit. When operating via the SoC, the capabilities described herein regarding the client switching protocol can be operated via dedicated logic integrated on a single integrated circuit (chip) along with other components of the computing device 500. Embodiments of this disclosure can also be practiced using other technologies (including mechanical, optical, fluid, and quantum technologies) capable of performing logical operations (e.g., AND, OR, and NOT). Furthermore, embodiments of this disclosure can be practiced within a general-purpose computer or in any other circuit or system.

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

[0091] As used herein, the term computer-readable medium may include computer storage media. Computer storage media may include volatile and non-volatile, removable and non-removable media implemented using any method or technology 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 examples of computer storage media (e.g., memory storage). Computer storage media may include RAM, ROM, electrically erasable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile disc (DVD) or other optical storage, magnetic tape cassette, magnetic tape, disk storage or other magnetic storage devices, or any other article of manufacture that can be used to store information and is accessible by computing device 500. Any such computer storage medium may be part of computing device 500. Computer storage media does not include carrier waves or other propagated or modulated data signals.

[0092] Communication media can be implemented from computer-readable instructions, data structures, program modules, or other data in modulated data signals such as carrier waves or other transmission mechanisms, and include any information transmission medium. The term "modulated data signal" can describe a signal having one or more characteristics set or altered in a manner that encodes information in the signal. As an example, communication media can include wired media such as wired networks or direct-line connections, and wireless media such as acoustic, RF, infrared, and other wireless media.

[0093] In one aspect, this technology relates to a system for routing video streams in a One-Way Transmission (OWT) system. The system includes: a source video agent, in a source computing environment, which: receives a video stream at an ingress port at an ingress Internet Protocol (IP) address; accesses a mapping table storing unique identifiers for the video stream based on the corresponding ingress IP address and port; identifies the unique identifier for the video stream based on the ingress port and IP address; identifies a reserved channel among multiple channels based on the unique identifier, the multiple channels defining different data paths through the OWT system; and transmits the video stream through the OWT system along the data paths defined by the reserved channels. The system also includes a destination video agent, in a destination computing environment protected by the OWT system, which: receives the video stream on a reserved channel; determines a destination address for the video stream from a routing table based on the reserved channel, the routing table storing corresponding destination addresses for multiple different channels among the multiple channels; and transmits the video stream to a destination device with the destination address.

[0094] In one example, the source computing environment is a low-trust environment, and the destination computing environment is a high-trust computing environment. In another example, identifying the reserved channel includes querying a mapping table using a unique identifier for the video stream. In yet another example, the data path used for the reserved channel identifies a specific protection in the OWT system and the output port of that specific protection. In yet another example, identifying the destination address includes querying a routing table using an identifier for the reserved channel and responding by receiving the destination address. In yet another example, determining the destination address by the destination video proxy includes: performing a first query of the routing table using the reserved channel; responding to the first query by receiving a unique identifier for the video stream; performing a second query of the routing table using the unique identifier; and responding to the second query by receiving the destination address.

[0095] In another aspect, a computer-implemented method for routing video streams in a One-Way Transmission (OWT) system is disclosed. The method includes: receiving a new channel command to reserve a channel among multiple channels for a video stream associated with a unique identifier, the multiple channels defining different data paths through the OWT system; identifying unused channels among the multiple channels; reserving the unused channel for the video stream associated with the unique identifier; receiving the video stream by a source video agent; identifying the unique identifier for the video stream by the source video agent based on the source address of the video stream; identifying the 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 agent; receiving the video stream on the reserved channel by a destination video agent in a destination computing environment; determining the 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 agent.

[0096] In one example, identifying a unique identifier by the source video proxy includes: accessing a mapping table storing unique identifiers for the video stream based on the source address of the video stream; and identifying the unique identifier for the 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 the source video proxy includes: querying the source mapping table using the unique identifier for the video stream. In yet another example, determining the destination address by the destination video proxy includes: querying the destination routing table using the reserved channel. In yet another example, the 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 the destination address by the destination video proxy includes: performing a first query of the destination routing table using the reserved channel; receiving the unique identifier for the video stream in response to the first query; performing a second query of the destination routing table using the unique identifier; and receiving the destination address in response to the second query. In another example, the method further includes: generating an acknowledgment message that the reserved channel has been reserved.

[0097] In another aspect, this technology relates to a method for routing video streams in a One-Way Transmission (OWT) system. The method includes: receiving, by a destination video agent in a destination computing environment, a first video stream on a first predefined channel of the OWT system and a second video stream on a second predefined channel of the OWT system; determining a first destination address for the first video stream by querying a source routing table using an identifier for the first predefined channel, wherein the source routing table includes entries indicating at least one of a unique identifier associated with a reserved channel or a destination address; determining a second destination address for the second video stream by querying the source routing table using an identifier for the second predefined 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.

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

[0099] For example, the aspects of this disclosure are described above with reference to block diagrams and / or operational illustrations of methods, systems, and computer program products according to various aspects of this disclosure. Functions / actions indicated in the boxes may not occur in the order shown in any flowchart. For example, depending on the functions / actions involved, two boxes shown consecutively may actually be executed substantially simultaneously, or these boxes may sometimes be executed in reverse order.

[0100] The descriptions and illustrations of one or more aspects provided in this application are not intended to limit or restrict the scope of the claimed disclosure in any way. The aspects, examples, and details provided in this application are considered sufficient to convey ownership and enable others to make and use the best mode of the claimed disclosure. The claimed disclosure should not be construed as limited to any aspect, example, or detail provided in this application. Various features (structures and methods) are intended to be selectively included or omitted, whether shown and described in combination or separately, to produce embodiments with a particular set of features. Having provided the descriptions and illustrations of this application, those skilled in the art can conceive of variations, modifications, and substitutions falling within the spirit of the broader aspects of the general inventive concept embodied in this application, without departing from the broader scope of the claimed disclosure.

Claims

1. A system for routing video streams in a one-way transport (OWT) system, the system comprising: a source video proxy (104) in a source computing environment (101): receiving a video stream on an ingress port at an ingress internet protocol (IP) address; accessing a mapping table storing unique identifiers for video streams based on the corresponding ingress IP address and port of the video stream; identifying a unique identifier for the video stream based on the ingress port and IP address of the video stream; identifying a reserved channel of a plurality of channels based on the unique identifier, the plurality of channels defining different data paths through the OWT system; and transmitting the video stream through the OWT system along the data path defined by the reserved channel; and a destination video proxy (110) in a destination computing environment (103) protected by the OWT system: receiving the video stream on the reserved channel; determining a destination address for the video stream from a routing table based on the reserved channel, the routing table storing corresponding destination addresses for a plurality of different channels of the plurality of channels; and transmitting the video stream to a destination device having the destination address.

2. The system of claim 1, wherein the source computing environment is a low trust environment and the destination computing environment is a high trust computing environment.

3. The system of claim 1, wherein identifying the reserved channel comprises: querying the mapping table with the unique identifier for the video stream.

4. The system of claim 1, wherein the data path for the reserved channel identifies a particular guard in the OWT system and an output port of the particular guard.

5. The system of claim 1, wherein identifying the destination address comprises: querying the routing table with an identifier for the reserved channel and receiving the destination address in response.

6. The system of claim 1, wherein determining the destination address by the destination video proxy comprises: performing a first query of the routing table with the reserved channel; receiving the 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.

7. A computer-implemented method for routing video streams in a one-way transport (OWT) system, the method comprising: receiving (402) a new channel command to reserve a channel for a video stream associated with a unique identifier in a plurality of channels, the plurality of channels defining different data paths through the OWT system; identifying an unused channel of the plurality of channels; reserving (404) the unused channel for the video stream associated with the unique identifier; receiving (406) the video stream by a source video proxy; identifying, by the source video proxy, a unique identifier for the video stream based on the source address of the video stream; identifying (408) the reserved channel for the video stream based on the unique identifier; transmitting (410) the video stream by the source video proxy through the OWT system along the reserved channel; ​ receiving (412), by a destination video agent in a destination computing environment, the video stream on the reserved channel; determining (414), based on the reserved channel, a destination address for the video stream; and transmitting (416), by the destination video agent, the video stream to a destination device having the destination address.

8. The method of claim 7, wherein identifying, by the source video agent, the unique identifier comprises: accessing a mapping table storing unique identifiers for video streams based on a source address of the video stream; and identifying the unique identifier for the video stream based on the source address of the video stream.

9. The method of claim 7, wherein reserving the reserved channel comprises: generating corresponding entries in a source mapping table and a destination routing table.

10. The method of claim 9, wherein identifying, by the source video proxy, the reserved channel comprises: querying the source mapping table with the unique identifier for the video stream.

11. The method of claim 9, wherein determining the destination address by the destination video proxy comprises: querying the destination routing table with the reserved channel.

12. The method of claim 9, further comprising: removing the reservation of 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 method of claim 9, wherein determining, by the destination video agent, the destination address comprises: performing a first query of the destination routing table with the reserved channel; receiving the unique identifier for the video stream in response to the first query; performing a second query of the destination routing table with the unique identifier; and receiving the destination address in response to the second query.

14. The method of claim 13, further comprising: generating an acknowledgement message that the reserved channel has been reserved.

15. A method for routing video streams in an oneway transmission (OWT) system, the method comprising: receiving (412), by a destination video agent in a destination computing environment, a first video stream on a first predefined channel of the OWT system and a second video stream on a second predefined channel of the OWT system; determining (414) a first destination address for the first video stream by querying a source routing table with an identifier for the first predefined channel, wherein the source routing table comprises entries indicating at least one of a unique identifier or a destination address associated with a reserved channel; determining (414) a second destination address for the second video stream by querying the source routing table with an identifier for the second predefined channel; transmitting (416) the first video stream to a first destination device having the first destination address; and transmitting (416) the second video stream to a second destination device having the second destination address.

Images