Configurable Route Table Limits for VPN Resource Management
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Current metrics for charging Internet Service Providers (ISPs) for VPN services do not accurately reflect actual resource utilization, and there is a need to prevent unauthorized resource requests that could flood the ISP infrastructure.
Innovation Solution
A system that stores route tables at the edge of the service provider network, sets route count limits, and monitors resource usage to accurately charge customers and prevent unauthorized access, allowing for dynamic modification of limits based on time and user activity.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Productivity
If dynamic route allocation is used to allocate resources on an as-needed basis, then resource utilization efficiency is improved, but it becomes difficult to accurately monitor and control actual resource usage for billing purposes
Solution Approach 1:
The patent segments route tables into customer-specific virtual route tables (VRFs) isolated by routing tables. Each customer's routes are tracked separately through unique routing table identifiers, enabling precise measurement of individual customer resource consumption while maintaining efficient dynamic allocation. The segmentation allows the system to monitor exactly which routes belong to which customer without interfering with other customers' allocations.
Solution Approach 2:
The patent implements feedback mechanisms where the system continuously monitors route table entries and provides accurate billing information back to customers. The monitoring process tracks the number of routes in each customer's VRF and uses this feedback data to generate accurate bills, creating a closed-loop system that ensures measurement accuracy while maintaining dynamic resource allocation.
2Adaptability or versatility
If route tables are allowed to grow without limits to accommodate dynamic VPN needs, then service flexibility is improved, but the risk of infrastructure flooding by unauthorized requests increases
Solution Approach 1:
The patent applies preliminary action by setting maximum route table size limits before VPN services are fully established. The system pre-configures maximum entry counts for routing tables and enforces these limits during route installation. This prevents unauthorized or excessive route requests from flooding the infrastructure while still allowing dynamic allocation up to the predetermined maximum, balancing flexibility with security.
Solution Approach 2:
The patent applies local quality by implementing different route limit policies for different customers and VPN types. Each customer's VRF can have customized maximum route table sizes based on their specific needs and risk profiles. This allows the system to maintain high service flexibility for trusted customers while applying stricter limits to potentially malicious or resource-intensive connections, thereby preventing infrastructure flooding at the local level.
3Device complexity
If static route allocation is used to provide constant set of resources, then resource control is simplified, but it cannot accurately reflect actual utilization for billing
Solution Approach 1:
The patent transitions from static to dynamic route allocation while maintaining controlled complexity through virtual route tables. The system dynamically tracks the number of routes in each customer's VRF in real-time, allowing accurate measurement of actual utilization. The dynamics are managed through automated monitoring and accounting mechanisms that continuously update route counts without requiring complex manual configuration, thus achieving both accuracy and manageable complexity.
Data Source
AI summary
A number of route tables are stored in a server at the edge of a service provider network, and are used to connect a set of customer sites to VPNs provided by the service provider. The forwarding entries in the route tables describe how packets conveyed over associated VPNs are to be forwarded between the service provider network and customer equipment systems. The disclosed system provides a configuration process for the route table including a route count limit as a parameter. The route count limit parameter provided through the configuration process is associated with the route table, and may be stored at the provider edge system, as well as at each other packet forwarding device within the network infrastructure of the service provider. Each forwarding device in the service provider infrastructure stores the route count limit, and further operates to keep track of the current number of routes inserted into the route table. Once the route table reaches the route count limit associated with it, new route requests can be either rejected, or accepted, based on a predetermined policy configuration. If new route requests are accepted, then the number of routes exceeding the route count limit is taken into account when charging the associated customer for service.