Cross-Domain Service Function Chaining via Network Service Headers
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing service function deployments are static and inflexible, failing to adapt to elastic service environments enabled by virtualization, and require agile service insertion models for dynamic and elastic service delivery across multiple network domains.
Innovation Solution
A system and method that configures nodes to communicate across administrative domains for service function chaining, using a service function chain description to steer and direct traffic through service nodes in multiple domains, with a service classifier introducing a network service header to facilitate communication between forwarding nodes across domains.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If service functions are deployed statically and bound to network topology, then deployment simplicity is maintained, but service flexibility and adaptability to elastic environments deteriorate
Solution Approach 1:
The patent implements dynamic service function chaining by enabling service functions to be instantiated at multiple locations across different administrative domains and dynamically selected based on service chain descriptions. The system allows service paths to be reconfigured in real-time without being bound to static network topology, enabling elastic service environments to adapt to changing demands while maintaining manageable complexity through automated orchestration.
Solution Approach 2:
The patent segments service functions into independent, virtualized units that can be deployed across multiple administrative domains. Each service function is instantiated as a separate entity that can be individually selected and chained together based on service requirements. This segmentation enables flexible service composition while simplifying deployment through modular, domain-independent service units.
2Adaptability or versatility
If nodes are configured to communicate across administrative domains for service function chaining, then service delivery flexibility improves, but domain autonomy and security boundaries deteriorate
Solution Approach 1:
The patent introduces service chain descriptions as intermediary structures that mediate between different administrative domains. These descriptions define service function chains that span multiple domains without requiring direct node-to-node communication across domain boundaries. The intermediary mechanism enables flexible cross-domain service delivery while preserving domain autonomy by abstracting inter-domain communication through standardized service chain definitions.
3Adaptability or versatility
If service functions are virtualized across geographically distributed data centers, then service elasticity improves, but coordination complexity across multi-network domains deteriorates
Solution Approach 1:
The patent implements a universal service chain description framework that can describe and orchestrate service functions across geographically distributed data centers and multiple network domains. This universal mechanism provides a single, consistent approach for coordinating service functions regardless of their physical location or domain affiliation, enabling service elasticity while reducing coordination complexity through standardized, multi-domain applicable descriptions.
Data Source
AI summary
In one or more embodiments, one or more systems, methods, and/or processes may receive a service function chain description that includes service functions associated with multiple domains, and rather than any of the domains ignoring or rejecting outside nodes, nodes may be configured to communicate with the outside nodes in implementing a service function chain associated with the service function chain description. For example, an arbiter (e.g., a central arbiter) may provide control information and/or configuration information, based on the service function chain description, to one or more systems of each domain. In one instance, the arbiter may provide the control information and/or the configuration information to a border node of each domain. In another instance, the arbiter may provide the control information and/or the configuration information to a domain controller of each domain.