OpenFlow Gateway Encapsulates IP Control Messages

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Existing communication methods between OpenFlow networks and conventional IP networks require processing of TCP/IP protocol stacks twice, leading to increased overhead and resource strain on OpenFlow controllers, especially during critical events.

Innovation Solution

An OpenFlow switch converts IP network control plane protocol messages into OpenFlow control messages, carrying payload information, protocol type, and identification details, allowing the OpenFlow controller to process messages without needing to handle TCP/IP stacks twice, thereby reducing overhead and improving resource utilization.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Adaptability or versatility

If the OpenFlow controller processes TCP/IP protocol stacks twice for IP network control plane protocol messages, then communication between OpenFlow devices and IP network devices can be achieved, but computational overhead and resource strain on the OpenFlow controller increase significantly

Engineering Contradiction:
Improvecommunication capabilityVSAvoidcomputational overhead
Core Design Contradiction:
Adaptability or versatilityVSUse of energy by moving object

Solution Approach 1:

The patent introduces a gateway device as an intermediary between the IP network and OpenFlow network. The gateway device parses IP network control plane protocol messages and converts them into OpenFlow protocol messages, thereby eliminating the need for the OpenFlow controller to process TCP/IP protocol stacks twice. This intermediary approach maintains communication capability while significantly reducing computational overhead on the controller.

Inventive Principle:
Principle #24Intermediary (Mediator)

Solution Approach 2:

The patent segments the protocol processing function by separating the TCP/IP stack processing from the OpenFlow controller. The gateway device handles the TCP/IP protocol processing independently, while the OpenFlow controller only needs to handle the simplified OpenFlow protocol messages. This segmentation allows the controller to focus on control plane functions without the burden of dual protocol stack processing.

Inventive Principle:
Principle #1Segmentation

2Adaptability or versatility

If the OpenFlow controller processes TCP/IP protocol stacks twice, then protocol compatibility is maintained, but processing speed and event response time deteriorate

Engineering Contradiction:
Improveprotocol compatibilityVSAvoidprocessing speed
Core Design Contradiction:
Adaptability or versatilityVSSpeed

Solution Approach 1:

The gateway device acts as an intermediary that pre-processes IP network control plane protocol messages before they reach the OpenFlow controller. By performing protocol conversion and parsing at the gateway level, the system maintains protocol compatibility while enabling faster processing at the controller, as the controller receives already-parsed OpenFlow messages rather than raw TCP/IP packets.

Inventive Principle:
Principle #24Intermediary (Mediator)

3Extent of automation

If the OpenFlow controller handles all protocol processing, then centralized control is maintained, but system complexity and resource requirements increase

Engineering Contradiction:
Improvecentralized controlVSAvoidcontroller complexity
Core Design Contradiction:
Extent of automationVSDevice complexity

Solution Approach 1:

The patent segments the system functionality by introducing a gateway device that handles protocol-specific processing tasks. This segmentation reduces the complexity of the OpenFlow controller while maintaining centralized control, as the gateway operates under the coordination of the controller but handles the burden of dual protocol stack processing independently.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The gateway device provides self-service by autonomously handling the parsing and conversion of IP network control plane protocol messages into OpenFlow messages. This self-service capability reduces the processing burden on the OpenFlow controller while maintaining centralized control architecture, as the gateway independently manages protocol conversion tasks.

Inventive Principle:
Principle #25Self-service

Data Source

PatentUS10182132B2Method, apparatus and system for communication between OpenFlow device and IP network device
Publication Date: 2019.01.15 HUAWEI TECH CO LTD
  • US10182132B2 patent drawing
  • US10182132B2 patent drawing
  • US10182132B2 patent drawing

AI summary

Embodiments of the present disclosure provide a method, an apparatus, and a system for communication between an OpenFlow device and an IP network device. According to the embodiments of the present disclosure, an OpenFlow control message is used to carry payload information, a field value that is in a packet header and that is used to determine a protocol type, and identification information of the IP network device that are in a TCP/IP data packet of an IP network control plane protocol message in order to encapsulate the IP network control plane protocol message into the OpenFlow control message for transmission between an OFS and an OFC, such that communication between the OpenFlow device and the IP network device can be implemented, the OFC does not need to process a TCP/IP protocol stack twice, and extra overheads of the OFC are avoided.