Service Graph Network Management for Scalable Packet Forwarding
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Traditional methods for managing packet/application flow services in networks, such as the star/flower arrangement and service header-based routing, are inefficient and costly, leading to sub-optimal performance, high latency, and limited scalability due to the need for static configurations and centralized control, which can be complex to implement and resiliently manage dynamic feature networks.
Innovation Solution
The system employs a service graph-based approach using the Openflow protocol to dynamically configure network devices, allowing packets to be forwarded between an ordered set of feature peers without changing the application flow, and implements a one-to-N backup approach for feature peers to ensure resilient storage and management of state information, enabling efficient and scalable packet forwarding.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If a star/flower arrangement with feature switch is used to manage packet flow services, then service delivery is enabled, but costs increase and latency increases due to traffic being traversed twice between feature peers and feature switch
Solution Approach 1:
The patent introduces service graphs as an intermediary abstraction layer between packet flows and feature peers. Service graphs define ordered sequences of feature peer visits, enabling direct routing without requiring traffic to traverse back through the feature switch. This mediator (service graph) orchestrates the flow path to eliminate unnecessary hops.
Solution Approach 2:
The patent segments the service delivery path into discrete feature peer nodes arranged in ordered sequences defined by service graphs. Instead of a centralized star topology where all traffic funnels through the feature switch, the path is segmented into specific node sequences that can be directly routed, reducing traversal distance and latency.
2Device complexity
If static configuration of tunnel IDs and next hops in feature switch is used, then routing is simplified, but adaptability to dynamic feature networks is limited and reconfiguration is needed for failures
Solution Approach 1:
The patent implements dynamic service graphs that can be programmatically configured and modified without requiring static preconfiguration. Service graphs define ordered sequences of feature peer visits that can be dynamically adjusted based on network conditions, failures, or changing service requirements. The system transitions from static tunnel ID configuration to dynamic service graph-based routing.
Solution Approach 2:
The patent changes the routing parameter from static tunnel IDs to dynamic service graph definitions. Service graphs contain configurable parameters such as ordered feature peer sequences, visit conditions, and fallback paths that can be modified to adapt to dynamic network conditions without changing the underlying network infrastructure.
3Reliability
If dedicated replica of feature peers is provisioned for resilience, then failure resilience is achieved, but costs increase and complex configuration is required
Solution Approach 1:
The patent uses service graphs to define alternative paths through existing feature peer copies or equivalents. Instead of requiring dedicated 1:1 replicas for each feature peer, service graphs can route traffic through alternative feature peers that provide equivalent functionality, reducing the need for expensive dedicated replicas while maintaining resilience.
Solution Approach 2:
The patent pre-defines multiple service graphs with alternative feature peer sequences and fallback paths. When failures occur, the system can switch to pre-configured alternative service graphs without requiring complex real-time reconfiguration or dedicated standby replicas, simplifying the resilience implementation.
4Ease of operation
If service header-based routing with centralized service broker is used, then service routing is enabled, but scalability is limited and complexity increases due to centralized control
Solution Approach 1:
The patent extracts the service graph definition and routing logic from centralized service broker control and embeds it directly in the network devices (OpenFlow switches). Service graphs are programmed into the switches, enabling distributed execution of service routing decisions without requiring constant centralized broker involvement, thus improving scalability.
Solution Approach 2:
The patent makes service graphs universal objects that can be programmed into multiple OpenFlow switches and applied to multiple packet flows. A single service graph definition can be reused across different switches and flows, reducing the need for complex centralized coordination and enabling scalable deployment.
Data Source
AI summary
A device receives packets of an application flow, and inspects one or more of the packets of the application flow. The device determines, based on the inspection of the one or more packets, a service graph of feature peers for the packets of the application flow. The feature peers are associated with a network and the service graph includes an ordered set of the feature peers. The device creates a representation of the service graph. The representation includes an ordered set of feature elements that represent the feature peers of the service graph. The device provides the representation of the service graph to a controller device, and the controller device configures, based on the representation, the network with the service graph so that the packets of the application flow traverse the service graph.