Logical Router First Hop Identification in Virtualized Networks

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

In distributed virtualized networks, multicast routers may fail to identify themselves as first hop routers, leading to dropped multicast traffic, especially in software-defined virtualization networks where the control plane and forwarding information base are decoupled, and edge services gateways need to accurately identify as first hop routers to prevent multicast traffic loss.

Innovation Solution

A logical router in a distributed virtualized network determines if it is a first hop router by either sending a L3 hello message and analyzing responses or parsing the multicast message and using the Multicast Forwarding Information Base (MFIB) to identify its role in forwarding multicast traffic.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If a multicast router is directly connected to source hosts in traditional networks, then the router can easily identify itself as a first hop router, but in distributed virtualized networks where source hosts are in different L3 subnets, the router cannot identify itself as a first hop router, leading to multicast traffic being dropped

Engineering Contradiction:
Improvemulticast traffic delivery reliabilityVSAvoidnetwork architecture complexity
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The patent introduces a control plane as an intermediary between the data plane routers and the multicast traffic. The control plane executes on the first hop router and receives notifications from a separate control VM about multicast traffic originating in the network. This mediator allows the router to identify itself as a first hop router even when source hosts are in different L3 subnets, resolving the identification problem without requiring direct physical connection to all sources.

Inventive Principle:
Principle #24Intermediary (Mediator)

Solution Approach 2:

The patent segments the router functionality into separate components: a control plane that executes identification logic and a data plane that forwards multicast traffic. The control plane is further separated from the forwarding information base calculation, which is performed by a separate control VM. This segmentation allows the identification function to be independently implemented and notified of multicast sources without requiring the router to have direct knowledge of all source locations.

Inventive Principle:
Principle #1Segmentation

2Ease of operation

If the control plane executes on the first hop router, then the router can process multicast identification, but in software-defined virtualization networks where the control plane is separated from the forwarding information base calculation, the router cannot determine its role, causing traffic loss

Engineering Contradiction:
Improvemulticast traffic forwardingVSAvoidcontrol plane architecture
Core Design Contradiction:
Ease of operationVSDevice complexity

Solution Approach 1:

The control plane acts as an intermediary between the separate control VM that calculates forwarding information and the data plane router that forwards traffic. The control plane receives notifications from the control VM about multicast traffic and uses this information to determine whether the local router is a first hop router. This intermediary role enables multicast identification despite the separation of control functions.

Inventive Principle:
Principle #24Intermediary (Mediator)

Solution Approach 2:

The control plane is configured in advance to receive notifications from the control VM about multicast traffic sources. By having the control plane预先 set up with the ability to receive and process these notifications, the system enables the router to quickly determine its role as a first hop router when multicast traffic is detected, without requiring complex real-time analysis of network topology.

Inventive Principle:
Principle #10Preliminary action

3Adaptability or versatility

If edge services gateways are used in software-defined virtualization networks, then network services can be distributed, but the gateways cannot identify themselves as first hop routers, leading to multicast traffic being dropped

Engineering Contradiction:
Improvenetwork service distributionVSAvoidmulticast traffic delivery
Core Design Contradiction:
Adaptability or versatilityVSReliability

Solution Approach 1:

The control plane on the edge services gateway acts as an intermediary that receives notifications from the control VM about multicast traffic. This allows the gateway to identify itself as a first hop router even in the distributed architecture where services are separated from the core routing functions. The intermediary control plane bridges the gap between the distributed service architecture and the multicast identification requirement.

Inventive Principle:
Principle #24Intermediary (Mediator)

Solution Approach 2:

The control plane is designed to perform multiple functions: it calculates forwarding information, receives multicast traffic notifications, and determines first hop router status. This multi-functional control plane enables edge services gateways to participate in multicast routing despite their specialized role in the distributed architecture, making the system more adaptable while maintaining reliability.

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

Data Source

PatentUS11032186B2First hop router identification in distributed virtualized networks
Publication Date: 2021.06.08 VMWARE INC
  • US11032186B2 patent drawing
  • US11032186B2 patent drawing
  • US11032186B2 patent drawing

AI summary

A method for identifying a first hop router (“FHR”) in a distributed virtualized network is presented. In an embodiment, a method comprises receiving a multicast message on an incoming interface. In response to receiving the multicast message, the router determines whether the router is a FHR for the multicast message, i.e., whether, in response to generating and transmitting a hello multicast message, the router does not receive a response on the incoming interface; or whether an interface to a RP for the multicast message is different than the incoming interface. If the router is the FHR for the multicast message, then the router determines an IP address of a RP for the multicast message. The router also encapsulates the multicast message into a unicast message, includes in the unicast message the IP address of the RP as a destination address, and transmits the unicast message to the RP.