SDN Controller Negotiation with Hardware Abstraction Layer
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Conventional Software Defined Networking (SDN) approaches fail to fully leverage the architecture of target devices when implementing forwarding behavior, often requiring proprietary information and making assumptions about table usage and pipeline design that do not align with actual device capabilities, leading to inefficient forwarding plane operations.
Innovation Solution
A negotiation process between a controller and a target forwarding or switching device using an abstract candidate device model that specifies intended forwarding behavior, with a Hardware Abstraction Layer (HAL) analyzing and implementing the supported behavior based on the device's architecture, allowing for flexible and efficient configuration of forwarding behavior.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Productivity
If conventional SDN approaches provide detailed device models with assumptions about table usage and pipeline design, then forwarding behavior can be implemented, but device architecture efficiency is not fully leveraged and vendor-specific information is required
Solution Approach 1:
The patent introduces a hardware abstraction layer (HAL) as an intermediary between the controller and the target device. The HAL translates abstract forwarding rules from the controller into device-specific instructions without requiring the controller to know vendor-specific details. This mediator enables efficient forwarding plane operations while maintaining controller independence from device complexity.
Solution Approach 2:
The system segments the forwarding plane control into two independent parts: the controller that generates abstract forwarding rules and the HAL that handles device-specific implementation details. This segmentation allows each component to be optimized independently - the controller for productivity and the HAL for adapting to device complexity.
2Adaptability or versatility
If abstract candidate device model is used to specify intended forwarding behavior, then vendor-specific information is not required and confidentiality is maintained, but negotiation and analysis process is needed
Solution Approach 1:
The HAL performs preliminary analysis of the abstract candidate device model before implementation. By pre-evaluating whether the target device can support the mandatory behavior specified in the abstract model, the system avoids runtime failures and reduces the need for iterative negotiation, thus minimizing time loss while maintaining vendor independence.
3Adaptability or versatility
If mandatory and non-mandatory behavior specifications are included in the abstract device model, then forwarding behavior flexibility is improved, but model analysis complexity increases
Solution Approach 1:
The patent applies local quality by differentiating between mandatory and non-mandatory behavior in the abstract device model. The HAL analyzes only the mandatory behavior to determine basic compatibility, then selectively evaluates non-mandatory features based on device capabilities. This localized analysis approach maintains forwarding flexibility while reducing overall model analysis difficulty.
Data Source
AI summary
A negotiation process is conducted between a controller and a target forwarding or switching device with respect to an abstract candidate device model for a forwarding plane. The abstract candidate device model is provided by a controller and indicates intended forwarding or switching behavior for the target device that a controller desires to have implemented on the target device. The intended behavior is specified in terms of mandatory and non-mandatory behavior. A hardware abstraction layer (HAL) for the target device analyzes the abstract candidate device model and decides whether the mandatory and optional behavior that is specified by the model is supported given the architecture of the target. The HAL informs the controller whether the intended behavior is supported by the target. Additional behavior may be proposed and accepted or not before the model is finalized. The finalized model may then be implemented and used to control forwarding behavior on the target device.