Content-Centric Network On-Demand Distance Vector Routing

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Content-centric networks face inefficiencies in route table management due to the contradiction between limitless naming spaces and limited route table items, leading to slow route lookup and difficulty in aggregating route table entries.

Innovation Solution

An on-demand distance vector routing method utilizing route request, reply, and error packets to dynamically establish and maintain paths, reducing route table items and improving query efficiency by broadcasting route request packets (CCN_RREQ) and replying with route information (CCN_RREP), and deleting invalid paths using route error packets (CCN_RRER).

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Adaptability or versatility

If content-centric network uses limitless naming space for routing, then routing flexibility and content identification capability are improved, but route table size and complexity increase significantly

Engineering Contradiction:
Improverouting flexibilityVSAvoidroute table size
Core Design Contradiction:
Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The patent segments the routing information into two parts: a global routing table that stores only prefix-to-interface mappings (reducing table size) and local routing information stored at edge nodes (providing detailed routing flexibility). This segmentation allows the core network to maintain simple routing tables while edge nodes handle content-specific routing decisions.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The patent introduces a hierarchical dimension to routing by distinguishing between global prefix routing (for general traffic) and local content-specific routing (for precise content delivery). This dimensional separation allows routing flexibility to be achieved through local policies without increasing global route table complexity.

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

2Measurement precision

If content-centric network maintains comprehensive route tables for all content, then route lookup accuracy is improved, but route lookup speed decreases due to large table size

Engineering Contradiction:
Improveroute lookup accuracyVSAvoidroute lookup speed
Core Design Contradiction:
Measurement precisionVSSpeed

Solution Approach 1:

The patent segments routing lookup into two stages: first, a quick prefix-based lookup in the global routing table to determine the egress interface; second, a more detailed content-specific lookup at the edge node. This segmentation enables fast initial routing decisions while maintaining accuracy through local content knowledge.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The patent performs preliminary routing based on content prefixes before full content matching is required. By pre-computing prefix-to-interface mappings and caching them in global routing tables, the system prepares routing information in advance, enabling faster lookup when actual content requests arrive.

Inventive Principle:
Principle #10Preliminary action

3Device complexity

If content-centric network uses on-demand route establishment, then route table items are reduced, but route discovery time and network overhead increase

Engineering Contradiction:
Improveroute table itemsVSAvoidroute discovery time
Core Design Contradiction:
Device complexityVSLoss of time

Solution Approach 1:

The patent merges on-demand route discovery with interest packet forwarding. When an interest packet arrives without a matching route, the system initiates route discovery by forwarding the interest packet through the network, which simultaneously serves as both content request and route exploration. This merging eliminates separate route discovery overhead.

Inventive Principle:
Principle #5Merging (Combining)

Solution Approach 2:

The patent enables the interest packet itself to serve the dual purpose of content request and route discovery. The interest packet carries routing information and triggers route establishment along its transmission path, allowing the data plane to self-configure routing without requiring separate control plane operations.

Inventive Principle:
Principle #25Self-service

4Extent of automation

If content-centric network uses traditional routing protocols, then route update automation is improved, but route table aggregation capability deteriorates

Engineering Contradiction:
Improveroute update automationVSAvoidroute table aggregation
Core Design Contradiction:
Extent of automationVSDevice complexity

Solution Approach 1:

The patent extracts the aggregation function from traditional routing protocols and implements it specifically for content prefixes. Instead of using generic routing protocol aggregation, the system extracts and applies aggregation rules tailored to content naming conventions, allowing automated route updates while maintaining content-specific aggregation capabilities.

Inventive Principle:
Principle #2Taking out (Extraction)

Solution Approach 2:

The patent changes the routing parameters from traditional IP-address-based metrics to content-prefix-based metrics. This parameter change enables aggregation rules to be defined based on content naming patterns (e.g., aggregating all /video/ prefixes) rather than network topology, improving aggregation capability for content-centric routing.

Inventive Principle:
Principle #35Parameter changes

Data Source

PatentEP3200404B1Content-centric network on-demand distance vector route method
Publication Date: 2018.05.23 INST OF ACOUSTICS CHINESE ACAD OF SCI
  • EP3200404B1 patent drawingFigure 1~3
  • EP3200404B1 patent drawingFigure 4
  • EP3200404B1 patent drawingFigure 5

AI summary

The present invention relates to a content-centric network on-demand distance vector route method, comprising: a request source node of a required request route broadcasts a route request packet CCN_RREQ to other nodes in a network, and starts a route discovery process; after a target node receives the route request packet CCN_RREQ, replying with a route reply packet CCN_RREP; after the request source node receives the route reply packet CCN_RREP returned by the target node, establishing a path between the request source node and the target node according to the content of the route reply packet CCN_RREP.