Switch Fabric Link Failover via Local Port Remapping
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing switch fabric networks experience significant downtime and traffic disruptions during link failures due to the time-consuming process of rediscovering network topology and rerouting communications, especially in larger networks with multiple subnet managers.
Innovation Solution
A scalable framework that remaps traffic from a failed switch link to a secondary link using local mapping tables, notifying the subnet manager after the failover, and updates forwarding tables to minimize downtime and ensure continuous communication.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If a failover mechanism notifies the subnet manager and waits for topology rediscovery and rerouting, then network topology management is centralized and controlled, but traffic disruption time increases significantly
Solution Approach 1:
The system pre-computes and stores multiple alternative traffic paths in the forwarding tables before any link failure occurs. When a link fails, the source node immediately switches to a pre-calculated alternative path without waiting for subnet manager intervention, thus resolving the contradiction between centralized management and rapid failover.
Solution Approach 2:
The source node autonomously detects link failures and performs path switching using locally stored alternative paths, without requiring subnet manager involvement for each failover event. This self-service mechanism eliminates the time-consuming centralized reconfiguration process while maintaining network integrity.
2Area of stationary object
If multiple subnet managers coordinate for failover in larger switch fabrics, then network management coverage is extended, but coordination complexity and failover time increase
Solution Approach 1:
The network is divided into multiple subnets with their own subnet managers, each responsible for local topology management. Alternative paths are pre-computed within each subnet context, allowing independent failover decisions in each subnet without requiring cross-subnet coordination during failover events.
Solution Approach 2:
Alternative paths spanning multiple subnets are pre-computed and stored in forwarding tables during normal operation. When a link fails, the source node immediately uses the pre-stalled alternative path without requiring real-time coordination between multiple subnet managers, thus reducing coordination complexity.
3Measurement precision
If the system waits for updated forwarding tables from the subnet manager, then routing accuracy is ensured, but application connectivity is interrupted
Solution Approach 1:
Multiple alternative forwarding paths are pre-computed and stored in the source node's forwarding table before any link failure occurs. When a link fails, the source node immediately switches to an alternative path from the pre-stored table without waiting for subnet manager updates, ensuring both routing accuracy and continuous connectivity.
Solution Approach 2:
The source node maintains continuous traffic flow by switching to pre-computed alternative paths immediately upon link failure detection. This eliminates interruptions in application connectivity while the subnet manager performs its slower topology update and forwarding table redistribution process in the background.
Data Source
AI summary
The disclosed system handles a switch link failure in a switch fabric network. When a node in the switch fabric network detects a failure of a switch link coupled to the node, the system remaps traffic that is directed to a logical port number, which is currently mapped to a primary physical port number associated with the failed switch link, to a secondary physical port number associated with the alternative switch link. This remapping involves performing a lookup in a local mapping table at the node, wherein the local mapping table stores associations between logical port numbers and physical port numbers, wherein for each logical port number, the mapping table includes a primary physical port number and one or more secondary physical port numbers, which are associated with alternative switch links. The system notifies a subnet manager for the switch fabric network about the link failure and the remapping.