Distributed LLDP Management in Fabric Nodes

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Current solutions for Link Layer Discovery Protocol (LLDP) management in distributed fabric networking systems centralize processing on a master node, leading to scalability issues as the network grows, overburdening the master node and constraining dependent protocols like Data Center Bridging Capabilities Exchange (DCBX) and Channel Discovery and Configuration Protocol (CDCP).

Innovation Solution

Distributing LLDP management across multiple nodes in a distributed fabric, where each node maintains a local processor for managing LLDP neighbors and a switching processor for packet handling, with periodic synchronization of neighbor information between nodes to maintain a unified view for northbound applications.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Device complexity

If LLDP management is centralized on the master node, then protocol implementation is simplified, but scalability deteriorates as the distributed fabric grows

Engineering Contradiction:
ImproveLLDP management complexityVSAvoidScalability
Core Design Contradiction:
Device complexityVSProductivity

Solution Approach 1:

The patent segments LLDP management functionality by distributing it across multiple nodes in the fabric. Each node runs local LLDP daemons that independently manage LLDP operations for their respective ports, eliminating the single-point bottleneck at the master node and enabling horizontal scaling as the fabric grows.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The patent introduces a new architectural dimension by implementing LLDP management at the node level rather than solely at the fabric control plane level. This dimensional shift allows parallel LLDP operations across multiple nodes, transforming the system from vertically-scalable to horizontally-scalable architecture.

Inventive Principle:
Principle #17Another dimension (Dimensionality change)

2Stability of the object's composition

If LLDP management is centralized on the master node, then consistent LLDP information is maintained, but processing load on the master node increases

Engineering Contradiction:
ImproveLLDP information consistencyVSAvoidMaster node processing load
Core Design Contradiction:
Stability of the object's compositionVSPower

Solution Approach 1:

The patent segments the processing load by distributing LLDP operations across multiple nodes. Each node's local processor handles LLDP PDU generation, reception, and neighbor database maintenance independently, reducing the master node's processing burden while maintaining overall system consistency through coordinated updates.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

Each node performs self-service for LLDP management by maintaining its own local LLDP daemon and neighbor database. Nodes independently handle LLDP operations for their connected ports, reducing dependency on the master node and distributing the processing workload across the fabric infrastructure.

Inventive Principle:
Principle #25Self-service

3Productivity

If LLDP is scaled across multiple nodes, then processing capacity increases, but synchronization complexity increases

Engineering Contradiction:
ImproveProcessing capacityVSAvoidSynchronization complexity
Core Design Contradiction:
ProductivityVSDevice complexity

Solution Approach 1:

The patent implements feedback mechanisms where nodes periodically exchange LLDP neighbor information and synchronize their databases. The system monitors database consistency and triggers synchronization operations when discrepancies are detected, maintaining data integrity across distributed nodes through controlled feedback loops.

Inventive Principle:
Principle #23Feedback

Solution Approach 2:

The patent employs periodic synchronization actions where nodes exchange LLDP information at regular intervals. This periodic coordination maintains consistent LLDP databases across all nodes without requiring continuous communication, balancing synchronization needs with system performance and reducing overall synchronization complexity.

Inventive Principle:
Principle #19Periodic action

4Quantity of substance

If more networking devices are added to the distributed fabric, then network coverage expands, but LLDP PDU processing load on the master node increases

Engineering Contradiction:
ImproveNumber of networking devicesVSAvoidMaster node processing load
Core Design Contradiction:
Quantity of substanceVSPower

Solution Approach 1:

The patent segments LLDP processing responsibilities so that each node handles LLDP PDU generation and processing for its local ports independently. This segmentation allows the fabric to scale by adding more nodes without proportionally increasing the master node's processing load, as each new node adds its own local processing capacity.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The patent makes each node universally capable of performing LLDP management functions, not just the master node. Every node can generate, receive, and process LLDP PDUs, and maintain local neighbor databases. This multi-functionality distributes the processing load across all nodes, enabling the system to scale with network growth without overburdening any single node.

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

Data Source

PatentUS9743367B2Link layer discovery protocol (LLDP) on multiple nodes of a distributed fabric
Publication Date: 2017.08.22 LENOVO GLOBAL TECHNOLOGIES SWITZERLAND INTERNATIONAL GMBH
  • US9743367B2 patent drawing
  • US9743367B2 patent drawing
  • US9743367B2 patent drawing

AI summary

In one embodiment, a method for providing link layer discovery protocol (LLDP) to a distributed fabric includes sending a neighbor synchronization request message from a master node to one or more member nodes connected to the master node, the neighbor synchronization request message including a request for a recipient member node to send its LLDP neighbor information to the master node, receiving a neighbor synchronization update message at the master node from at least one of the one or more member nodes, the neighbor synchronization update message including information about local LLDP neighbors of the one or more member nodes, and storing the information about the local LLDP neighbors from the at least one of the one or more member nodes in a LLDP neighbors database of the master node.