Switch Clusters with L3 Distributed Router Functionality

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Conventional SDN controllers lack scalable Layer-3 (L3) communication support for switch clusters, relying on expensive TCAM-based tables with limited capacity, which hinders effective communication with non-SDN devices and networks.

Innovation Solution

Implementing a system with L3 Forwarding Tables, also known as Route Tables or Longest Prefix Match Tables, in each switch of the cluster, allowing for scalable L3 support by exposing these tables to SDN controllers via OpenFlow protocols, while retaining TCAM-based tables for non-SDN capable switches, and using virtual routers to manage traffic.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Adaptability or versatility

If TCAM-based OpenFlow tables are used for L3 communications, then L3 routing functionality is provided, but the number of supported routes is limited and implementation cost is high

Engineering Contradiction:
ImproveL3 routing capabilityVSAvoidnumber of supported routes
Core Design Contradiction:
Adaptability or versatilityVSQuantity of substance

Solution Approach 1:

The patent introduces L3 Forwarding Tables (L3 FIB) as an intermediary data structure between the SDN controller and the switch TCAM tables. The controller populates L3 FIB with routing entries, which are then translated and installed in the switch TCAM tables. This intermediary layer enables the system to support a much larger number of routes than the TCAM alone could handle directly, as the L3 FIB can maintain extensive routing information while only the most frequently used or critical entries are installed in the limited TCAM space.

Inventive Principle:
Principle #24Intermediary (Mediator)

2Adaptability or versatility

If TCAM-based tables are used for L3 communications, then L3 routing functionality is provided, but implementation cost increases

Engineering Contradiction:
ImproveL3 routing capabilityVSAvoidimplementation cost
Core Design Contradiction:
Adaptability or versatilityVSEase of manufacture

Solution Approach 1:

The patent creates a virtual copy of the routing table functionality through L3 Forwarding Tables in software (running on the SDN controller) rather than relying solely on hardware TCAM tables. This software-based L3 FIB copies and extends the routing capabilities, allowing the system to achieve L3 routing functionality with much lower cost since standard switches without expensive TCAM hardware can be used, while still providing comprehensive route support through the software-based forwarding table.

Inventive Principle:
Principle #26Copying

3Ease of operation

If conventional SDN controllers are used, then L2 communications are handled, but L3 communications are not supported

Engineering Contradiction:
ImproveL2 communication handlingVSAvoidL3 communication support
Core Design Contradiction:
Ease of operationVSAdaptability or versatility

Solution Approach 1:

The patent enhances the conventional SDN controller to perform multiple functions: it continues to handle L2 switching communications through standard OpenFlow protocols while simultaneously providing L3 routing functionality through the introduction of L3 Forwarding Tables and virtual router support. This multi-functional controller can process both L2 Ethernet frames and L3 IP packets, making the SDN infrastructure universally applicable to both data link layer and network layer communications without requiring separate specialized controllers.

Inventive Principle:
Principle #6Universality (Multi-functionality)

Data Source

PatentEP3031179B1Switch clusters having layer-3 distributed router functionality
Publication Date: 2019.10.16 INTERNATIONAL BUSINESS MACHINE CORPORATION
  • EP3031179B1 patent drawingFigure 1
  • EP3031179B1 patent drawingFigure 2
  • EP3031179B1 patent drawingFigure 3

AI summary

According to one embodiment, Layer-3 (L3) distributed router functionality is provided to a switch cluster by receiving an address resolution protocol (ARP) request packet from a first host at an entry switch in a switch cluster, a switch controller being in communication with the entry switch, and the ARP request packet including a virtual router IP address of the switch controller as a target, forwarding the ARP request packet to the switch controller after adding a header that adheres to a communication protocol used by the switch controller, receiving an ARP response packet from the switch controller indicating: a source IP address corresponding to a virtual router of the switch controller and a SMAC corresponding to the switch controller, forwarding the ARP response packet to the first host after stripping the communication protocol header, and setting the virtual router as a default gateway for traffic received from the first host.