SDN Interface Device for Optical and Wireless Networks
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing SDN solutions are limited in supporting optical and wireless networks, as well as IoT devices, due to their vendor-specific and packet-switched nature, which cannot handle analogue data transport and lack compatibility with modern switching technologies like flexi-WDM and wireless technologies beyond Wi-Fi.
Innovation Solution
An interface device with a vendor and technology-specific layer, device abstraction layer, and protocol mapping layer that translates control and message data between SDN controllers and network devices, enabling SDN control and monitoring through OpenFlow protocol for optical, wireless, and IoT devices, and allowing legacy devices to become programmable.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If OpenFlow protocol is used for SDN control, then packet-switched network devices can be controlled, but optical and wireless networks cannot be supported
Solution Approach 1:
The patent introduces an intermediary device positioned between the SDN controller and network devices that performs protocol translation. This intermediary translates OpenFlow protocol messages from the SDN controller into device-specific protocols (such as CLI, SNMP, or proprietary protocols) for optical and wireless devices, enabling compatibility without requiring the SDN controller to support multiple protocols directly.
Solution Approach 2:
The control plane is segmented into multiple components: the SDN controller using OpenFlow, the intermediary translation device, and the network devices. This segmentation allows each component to operate with its own protocol stack, with the intermediary handling the protocol conversion burden, thus resolving the contradiction between versatility and complexity.
2Ease of operation
If vendor-specific protocols are used for network devices, then device functionality is preserved, but SDN control and monitoring cannot be implemented
Solution Approach 1:
The intermediary device acts as a mediator that receives standardized OpenFlow commands from the SDN controller and translates them into vendor-specific protocol commands that the target network device can execute. This preserves the original device functionality while enabling SDN control through a standardized interface.
Solution Approach 2:
The intermediary device is designed with multi-functionality to support multiple vendor-specific protocols and device types. It can translate OpenFlow messages to various proprietary protocols (Cisco CLI, Juniper Junos, SNMP, etc.), making it a universal solution that bridges the gap between standardized SDN control and diverse vendor-specific devices.
3Adaptability or versatility
If digital packet switching is used, then SDN control works well, but analogue optical and wireless networks cannot be controlled
Solution Approach 1:
The intermediary device handles the complexity of mapping digital packet-switching concepts to analogue network operations. It translates OpenFlow flow table entries into configurations that make sense for analogue networks, such as mapping flow match fields to wavelength/frequency parameters for optical networks or to radio resource parameters for wireless networks.
Solution Approach 2:
The system performs parameter changes by mapping digital packet parameters (source/destination IP, port numbers, protocol types) to analogue network parameters (wavelengths, frequencies, power levels, modulation schemes). This parameter transformation enables SDN control of analogue networks while maintaining the digital OpenFlow interface.
Data Source
AI summary
An interface device (100) for interfacing between a network device (170-240) and a software-defined networking (SDN) controller (150), the interface device (100) comprising: a first interface (140) for connecting the interface device (100) to the SDN controller (150); a second interface (160) for connecting the interface device (100) to the network device (170-240); a vendor and technology specific layer module (110), which is operative to transmit control and message data to, and to receive control and message data from, the network device (170-240) in a native control and message data protocol of the network device; a device abstraction layer module (120), which is operative to generate a device abstraction model (400) representing capabilities of the network device (170-240); and a protocol mapping layer module (130), which is operative to map control and message data used by the network device (170-240) onto the device abstraction model (400), such that messages issued by the SDN controller (150) in its native message format can be transmitted to the network device in a native message format of the network device (170-240), and messages issued by the network device (170-240) in its native message format can be transmitted to the SDN controller (150) in the native message format of the SDN controller (150).