Bidirectional ACL Database Sharing for Network Scaling

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Existing bidirectional access control list (ACL) systems face challenges in scaling networks without sacrificing latency and throughput due to hardware resource constraints, particularly due to duplication of constant fields in ingress and egress ACL databases, which limits the number of ACL rules and inhibits network scaling.

Innovation Solution

Implementing a system with three ACL databases, where a separate constant ACL database is searched once and its results are shared with both ingress and egress variable ACL databases, eliminating duplicate storage and searches of constant fields, thereby increasing the number of ACL rules without impacting latency or throughput.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Adaptability or versatility

If separate constant fields are stored in both ingress and egress ACL databases, then ACL rule matching can be performed independently for each direction, but hardware resources are duplicated and ACL rule capacity is limited

Engineering Contradiction:
ImproveACL rule capacityVSAvoidhardware resources
Core Design Contradiction:
Adaptability or versatilityVSQuantity of substance

Solution Approach 1:

The patent merges the constant fields from separate ingress and egress ACL databases into a single shared constant ACL database. This consolidation eliminates duplicate storage of constant field entries, reducing hardware resource consumption while maintaining the ability to perform independent ACL matching for both ingress and egress traffic directions.

Inventive Principle:
Principle #5Merging (Combining)

Solution Approach 2:

The shared constant ACL database serves multiple functions by supporting both ingress and egress ACL matching operations simultaneously. A single database structure is designed to be universally accessible and usable for bidirectional traffic control, allowing the same hardware resources to fulfill multiple ACL enforcement roles.

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

2Productivity

If constant fields are duplicated in ingress and egress databases, then independent ACL processing is enabled, but hardware overhead increases and scaling is inhibited

Engineering Contradiction:
Improvenetwork scaling capabilityVSAvoidhardware overhead
Core Design Contradiction:
ProductivityVSLoss of energy

Solution Approach 1:

The patent combines duplicate constant field storage into a single shared database, eliminating redundant hardware resources. This merging reduces the overall hardware overhead required for ACL operations and frees up resources that can be used to increase network scaling capability and ACL rule capacity.

Inventive Principle:
Principle #5Merging (Combining)

3Reliability

If separate ACL databases are used for ingress and egress, then bidirectional access control is achieved, but hardware utilization efficiency decreases

Engineering Contradiction:
Improvebidirectional access controlVSAvoidhardware utilization efficiency
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The shared constant ACL database is designed with universal access capabilities that allow it to serve both ingress and egress ACL matching functions. The database structure incorporates direction-specific variable fields that enable bidirectional access control while sharing the constant field storage, thereby maintaining reliability without sacrificing hardware utilization efficiency.

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

Data Source

PatentEP2878113B1Improving hardware utilization for a bidirectional access control list in a low latency high-throughput network
Publication Date: 2017.09.06 CISCO TECHNOLOGY INC
  • EP2878113B1 patent drawingFigure 1
  • EP2878113B1 patent drawingFigure 2
  • EP2878113B1 patent drawingFigure 3

AI summary

A method in an example embodiment includes creating a first search key from variable data of a message received in a network environment, creating a second search key from constant data of the message, identifying a first database entry in a first database based on the first search key, and identifying a second database entry in a second database based on the second search key. The method can also include performing an action associated with the first database entry when a correlation is identified between the first and second database entries. In specific embodiments, the variable data are modified and the constant data are not modified. The first search key can be created prior or subsequent to forwarding the message. In further embodiments, the correlation is identified when an offset of the first database entry is the same as an offset of the second database entry.