Unified IB IP Address Resolution via Multicast Groups

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

High performance computing environments face performance and administrative bottlenecks due to traditional network and storage limitations, particularly in cloud computing architectures, where InfiniBand technology is used but struggles with efficient address and routing schemes, leading to challenges in live migration of virtual machines and scalability.

Innovation Solution

The implementation of combined IB and IP address and name resolution schemes via default IB multicast groups, utilizing a protocol with type-length-value (TLV) style generic representation to provide application-specific values, enabling efficient IB address mapping and announcement messages, and dynamic LID assignment to facilitate scalable and transparent live migration of virtual machines.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Productivity

If traditional network and storage schemes are used in InfiniBand environments, then compatibility with existing systems is maintained, but performance bottlenecks and scalability issues occur

Engineering Contradiction:
Improvenetwork performanceVSAvoidaddress resolution complexity
Core Design Contradiction:
ProductivityVSDevice complexity

Solution Approach 1:

The patent combines IB address resolution with IP address resolution by having the IB name server also function as an IP name server. This merging of functions allows the system to resolve both IB and IP addresses through a unified namespace, eliminating the performance bottlenecks of traditional separate resolution schemes while maintaining compatibility with existing IP-based systems.

Inventive Principle:
Principle #5Merging (Combining)

Solution Approach 2:

The name server is designed to provide universal address resolution capabilities for both IB and IP addresses. By implementing a unified namespace that can resolve both address types, the system achieves multi-functionality that improves network performance and scalability without requiring separate resolution mechanisms for each address type.

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

2Speed

If IB address mapping is performed through traditional SA access, then address resolution is achieved, but reconfiguration time and startup failover time increase

Engineering Contradiction:
Improveaddress resolution speedVSAvoidreconfiguration time
Core Design Contradiction:
SpeedVSLoss of time

Solution Approach 1:

The system performs preliminary address mapping by maintaining a unified namespace in the name server that pre-resolves both IB and IP addresses. This preliminary action eliminates the need for time-consuming SA access during runtime address resolution, significantly reducing reconfiguration time and startup failover time while improving address resolution speed.

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The unified namespace in the name server acts as an intermediary between IB address mapping requests and the actual address resolution. This intermediary mechanism eliminates the need for direct SA access, reducing reconfiguration time and improving address resolution speed by handling mappings through the name server's cached namespace information.

Inventive Principle:
Principle #24Intermediary (Mediator)

3Adaptability or versatility

If separate IB and IP address resolution schemes are used, then each protocol can be optimized independently, but administrative overhead and system complexity increase

Engineering Contradiction:
Improveprotocol optimization flexibilityVSAvoidadministrative overhead
Core Design Contradiction:
Adaptability or versatilityVSEase of operation

Solution Approach 1:

The patent merges separate IB and IP address resolution schemes into a unified namespace managed by a single name server. This combination maintains the adaptability and versatility of independent protocol optimization while significantly reducing administrative overhead by eliminating the need to manage separate resolution systems.

Inventive Principle:
Principle #5Merging (Combining)

Solution Approach 2:

The name server is designed with universal functionality to handle both IB and IP address resolution through a unified namespace. This multi-functionality allows each protocol to be optimized independently while presenting a unified management interface, thereby reducing administrative overhead without sacrificing protocol-specific optimization capabilities.

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

4Adaptability or versatility

If dynamic LID assignment is implemented to facilitate live migration, then virtual machine mobility is improved, but network reconfiguration complexity increases

Engineering Contradiction:
Improvevirtual machine mobilityVSAvoidnetwork reconfiguration complexity
Core Design Contradiction:
Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The unified namespace in the name server acts as an intermediary that simplifies dynamic LID assignment during live migration. By managing address mappings centrally, the name server reduces network reconfiguration complexity while maintaining improved virtual machine mobility through efficient address resolution during migration events.

Inventive Principle:
Principle #24Intermediary (Mediator)

Data Source

PatentUS10601765B2System and method to provide combined IB and IP address and name resolution schemes via default IB multicast groups in a high performance computing environment
Publication Date: 2020.03.24 ORACLE INT CORP
  • US10601765B2 patent drawing
  • US10601765B2 patent drawing
  • US10601765B2 patent drawing

AI summary

Systems and to provide combined IB and IP address and name resolution schemes via default IB multicast groups in a high performance computing environment, in accordance with an embodiment. A protocol would include options for providing application specific values using TLV (type-length-value) style generic representation. In this way it would be possible to issue requests that have an application specific argument (e.g. IP address) for which an IB address mapping is requested, and it would also be possible to have responses and announcement messages containing an arbitrary set of such TLVs.