SDN Controller Dynamic Service Chaining via OpenFlow
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing network configurations in software-defined networks (SDNs) are static and complex to reconfigure, making it difficult to provide optimal network paths for service chaining, especially when network states or service level agreements (SLAs) change, leading to inefficient management and billing.
Innovation Solution
A method for service chaining in SDN-based networks that dynamically adjusts network paths based on SLAs by using an SDN controller connected to multiple switches via the OpenFlow protocol, which extracts service and user identifiers from packets and uses service, user, and network function tables to forward packets through a database that manages network topology and functions.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If a static network path is configured for service hosting, then network stability is maintained, but the ability to provide optimal network paths for each service deteriorates
Solution Approach 1:
The patent implements dynamic service chaining by allowing the SDN controller to dynamically determine and update network paths based on current network state and service requirements. The controller receives packet-in messages, extracts service identifiers, queries the entry database for appropriate forwarding entries, and dynamically installs flow entries in switches to redirect traffic through appropriate network functions, enabling the network to adapt to changing conditions while maintaining stability through centralized control.
2Adaptability or versatility
If manual reconfiguration is performed according to network state changes, then network adaptability is improved, but system complexity and operational difficulty increase
Solution Approach 1:
The system implements automated self-service through the SDN controller that automatically responds to packet-in messages from switches, extracts service identifiers, queries the entry database for appropriate forwarding entries, and dynamically installs flow entries without human intervention. The controller autonomously manages service chaining configuration, path optimization, and network function selection based on real-time network state and service level agreements, eliminating complex manual reconfiguration processes.
3Manufacturing precision
If specialized network for each service is built and managed, then service-specific optimization is achieved, but management complexity becomes unmanageable
Solution Approach 1:
The patent implements a universal service chaining management approach where a single SDN controller manages multiple services through a unified architecture. The controller uses a common entry database that stores forwarding entries for multiple services, and a standardized process for handling packet-in messages regardless of service type. This universal management system provides service-specific optimization through customized network paths and functions while maintaining manageable complexity through centralized, standardized control procedures.
4Productivity
If dynamic service chaining is implemented, then optimal network paths for each service are provided, but system complexity increases
Solution Approach 1:
The SDN controller acts as an intermediary between switches and network functions, simplifying the dynamic service chaining process. The controller receives packet-in messages from switches, extracts service identifiers, queries the entry database for appropriate forwarding entries, and installs flow entries to direct traffic through optimal paths. This intermediary architecture enables dynamic path optimization and service-specific routing while managing complexity by centralizing control logic and providing a unified interface for all service chaining operations.
Data Source
AI summary
A method for providing service chaining in a software-defined network (SDN)-based network system, the method including: receiving, at a controller, a first packet-in message from a first switch of a plurality of switches, which has received a service request packet from a user, to indicate that the first switch does not have a corresponding entry in a field extracted from the service request packet; extracting from the packet-in message both a service identifier that identifies a type of a service requested through the service request packet and a user identifier that identifies the user; and searching an entry database for an entry list that enables the service request packet to be forwarded to a network function list that corresponds to the service identifier and the user identifier, with reference to a service table, a user table, and a network function table which are associated with one another.


