Bridge Pruning Virtual Services Metro Ethernet
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Current protocols for managing Ethernet virtual connections (EVCs) in Metro Ethernet networks fail to prevent bandwidth wastage due to inactive redundant paths, as traffic still floods over them, and existing VLAN-based pruning protocols like MVRP and VTP are ineffective beyond single VLAN granularity, especially with more than 4K services, and cannot efficiently manage gateway selection and topology convergence.
Innovation Solution
Implementing a bridge in the network that executes a spanning tree protocol (STP) and a registration protocol to generate 'fake' join messages for gateway ports, allowing efficient pruning of virtual connections without tunneling registration protocols through the provider network, using unique numerical IDs for EVCs and per-port flood control logic to manage traffic.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If redundant paths are provisioned for EVCs to improve network availability, then network reliability is improved, but bandwidth is wasted when redundant paths are inactive
Solution Approach 1:
The bridge proactively generates fake join messages for inactive gateway ports before traffic needs to be routed, preventing unnecessary traffic from being flooded over redundant paths. This preliminary action blocks traffic at the source rather than allowing wastage and then correcting it.
Solution Approach 2:
The solution segments the network traffic control by implementing per-EVC (Ethernet Virtual Connection) fake join message generation at each bridge, allowing independent control of traffic paths for different virtual services while maintaining overall network reliability through selective path activation.
2Adaptability or versatility
If VLAN-based pruning protocols (MVRP, VTP) are used to manage EVCs, then virtual service management is enabled, but the protocols fail to prune effectively beyond single VLAN granularity and 4K service limits
Solution Approach 1:
The invention changes the fundamental parameter of service identification from VLAN-based (single tag, 4K limit) to EVC-based (unique numerical IDs, beyond 4K services). This allows the system to manage a larger number of virtual services with finer granularity while maintaining compatibility with existing bridge infrastructure.
Solution Approach 2:
Instead of using traditional join/prune messages that propagate through the network to control traffic, the invention inverts the approach by having bridges generate fake join messages locally for inactive gateway ports. This reverses the traditional control mechanism and achieves more efficient pruning without relying on protocol tunneling through provider networks.
3Reliability
If multiple gateway ports are used for backbone network access to provide redundancy and load balancing, then gateway availability is improved, but loop prevention and bandwidth control become more difficult
Solution Approach 1:
The bridge acts as an intermediary that generates fake join messages for inactive gateway ports, mediating between the multiple gateway ports and the backbone network. This intermediary action prevents loops and bandwidth wastage by blocking traffic at the bridge level rather than requiring complex coordination between multiple gateways.
Solution Approach 2:
Each bridge independently generates fake join messages for its own inactive gateway ports based on local STP (Spanning Tree Protocol) state information. This self-service approach allows each bridge to autonomously manage its gateway redundancy without requiring complex inter-bridge coordination or protocol tunneling.
Data Source
AI summary
In one embodiment, a bridge in a computer network may execute a spanning tree protocol (STP) for network topology and a registration protocol for traffic control of virtual connections (e.g., EVCs) at the bridge. For any gateway ports of the bridge inter-connected with a provider network, the bridge may generate “fake” received registration protocol join messages for a particular virtual connection at the gateway port. The bridge may then either i) propagate the join messages, in response to the gateway port being in a forwarding state according to the STP, on other forwarding ports of the bridge, or ii) in response to the gateway port not being in a forwarding state, block propagation of the join messages to other ports of the bridge.