Grouped VPN Prefix Convergence via Next-Hop Indexing

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

The existing routing table convergence process in computer networks is inefficient, particularly when a large number of VPN prefixes are involved, leading to substantial time requirements for updating next-hop information, which can result in traffic loss due to delayed FIB updates.

Innovation Solution

Grouping VPN prefixes into sets with shared network border node next-hop options and using index values to manage VPN labels, allowing for prefix-independent convergence by updating shared border node lists instead of individual prefix entries.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If per-prefix re-linking is used to update routing tables when next-hop changes, then routing accuracy is maintained, but convergence time becomes substantially large when many prefixes are involved

Engineering Contradiction:
Improverouting accuracyVSAvoidconvergence time
Core Design Contradiction:
ReliabilityVSLoss of time

Solution Approach 1:

The patent segments the routing table into two independent components: a prefix table storing prefix-to-next-hop mappings and a next-hop table storing next-hop-to-label mappings. When a next-hop changes, only the next-hop table entry is updated, not all prefix entries. This segmentation resolves the contradiction by maintaining routing accuracy through proper table structure while dramatically reducing convergence time by limiting updates to a single next-hop table entry regardless of the number of prefixes.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The patent extracts the next-hop information from the prefix entries and stores it separately in a dedicated next-hop table. This extraction allows the prefix table to remain stable while the next-hop table handles all dynamic updates. The contradiction is resolved because routing accuracy is maintained through the intact prefix-to-next-hop relationships in the prefix table, while convergence time is reduced by confining updates to the extracted next-hop table only.

Inventive Principle:
Principle #2Taking out (Extraction)

2Measurement precision

If routing tables store detailed prefix-next-hop mappings for all VPN prefixes, then routing precision is maintained, but memory usage becomes substantial

Engineering Contradiction:
Improverouting precisionVSAvoidmemory usage
Core Design Contradiction:
Measurement precisionVSQuantity of substance

Solution Approach 1:

The patent merges the storage of prefix information and next-hop information into a unified routing system with two tables that reference each other. The prefix table stores prefix-to-next-hop-index mappings, and the next-hop table stores next-hop-index-to-label mappings. This merging allows routing precision to be maintained through the prefix table while memory usage is optimized by sharing next-hop information across multiple prefixes through the index-based reference system in the next-hop table.

Inventive Principle:
Principle #5Merging (Combining)

Solution Approach 2:

The next-hop table serves as a universal repository that can be referenced by multiple prefix entries through index values. Instead of duplicating next-hop information in each prefix entry, the universal next-hop table is updated once and automatically applies to all relevant prefixes. This resolves the contradiction by maintaining routing precision through the prefix table's detailed mappings while reducing memory usage through the shared, multi-functional next-hop table.

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

3Reliability

If individual prefix entries are updated when next-hop changes, then routing correctness is ensured, but update overhead becomes substantial for large numbers of prefixes

Engineering Contradiction:
Improverouting correctnessVSAvoidupdate efficiency
Core Design Contradiction:
ReliabilityVSProductivity

Solution Approach 1:

The patent segments the routing update process into two independent operations: updating the prefix table with prefix-to-index mappings and updating the next-hop table with index-to-label mappings. When a next-hop changes, only the next-hop table is updated, not individual prefix entries. This segmentation ensures routing correctness is maintained through the prefix table's stable mappings while dramatically improving update efficiency by reducing the update scope to a single next-hop table entry regardless of the number of affected prefixes.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The patent introduces an index value as an intermediary between prefix entries and next-hop information. The prefix table stores prefix-to-index mappings, and the next-hop table stores index-to-label mappings. This intermediary index system allows routing correctness to be maintained through the prefix table's detailed mappings while improving update efficiency by enabling bulk updates through the single next-hop table, which all prefixes reference indirectly through their index values.

Inventive Principle:
Principle #24Intermediary (Mediator)

Data Source

PatentUS8867334B2Efficient convergence of grouped VPN prefixes
Publication Date: 2014.10.21 CISCO TECHNOLOGY INC
  • US8867334B2 patent drawing
  • US8867334B2 patent drawing
  • US8867334B2 patent drawing

AI summary

In one embodiment, a list of border node next hop options is maintained in a memory. The list of border node next hop options includes one or more of border nodes that may be utilized to reach one or more prefixes. An index value is associated with each border node of the list of border node next hop options. A list of labels is also maintained in the memory. The index value of each border node is associated with a corresponding label for a path to reach that border node. When a change to the one or more border nodes is detected, the list of border node next hop options is updated to remove a border node. However, a label for the path to reach the border node is maintained in the list of labels for at least a period of time.