PBB Multicast Addressing for Service Differentiation
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
In Provider Backbone Bridge Networks (PBBNs), the encapsulation of customer multicast frames with a Default Backbone Destination Address prevents differentiation and efficient pruning of customer multicast services, limiting control over individual services due to layer violations and encapsulation methods.
Innovation Solution
Customer multicast frames are encapsulated with a Backbone Destination Address equal to the original Customer Destination Address, enabling independent control through the 'EnableCustomerMulticast' parameter, allowing MMRP or IGMP snooping protocols to operate seamlessly across domains.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If customer multicast frames are encapsulated with Default Backbone Destination Address according to IEEE Std 802.1ah-2008, then backbone connectivity is established, but customer multicast service differentiation and individual control are lost
Solution Approach 1:
The patent segments the backbone destination address selection into two distinct cases: (1) unicast frames continue to use Default Backbone Destination Address for reliable delivery, and (2) multicast frames use the original customer multicast group address to enable service differentiation. This segmentation allows both reliability and adaptability to coexist by applying different addressing strategies to different frame types.
Solution Approach 2:
Instead of following the conventional approach where all backbone frames use Default Backbone Destination Address, the patent inverts the approach for multicast frames by using the original customer multicast group address as the backbone destination address. This inversion enables IGMP snooping and MMRP protocols to function in the backbone, providing individual control over customer multicast services.
2Loss of energy
If IGMP snooping is used to prune multicast trees, then resource efficiency is improved, but layer violation between L3 IP and L2 Ethernet causes problems in PBBNs
Solution Approach 1:
The patent introduces a mediation mechanism at the backbone edge bridges that translates customer multicast group addresses into appropriate backbone frame addressing. This intermediary function allows IGMP snooping to operate on customer multicast frames without causing layer violations in the backbone, as the multicast group addresses are properly handled during encapsulation and decapsulation processes.
3Ease of operation
If MMRP protocol is used for L2 multicast registration, then multicast control is enabled, but it is insufficient when IGMP packets are encapsulated and hidden in PBBN
Solution Approach 1:
The patent extends the scope of MMRP from purely L2 operation to operate across the L3 encapsulated environment by using the original customer multicast group address as the backbone destination address. This dimensional change allows MMRP to register multicast groups that are encapsulated with L3 headers, making previously hidden IGMP messages visible and controllable through MMRP in the backbone network.
Data Source
AI summary
A method and Provider Backbone Bridge (PBB) for handling customer multicast frames that are received by a Customer Network Port or Provider Network Port on an I-component of the PBB. Customer multicast frames that are forwarded to a Virtual Instance Port (VIP) on the I-component are encapsulated with a Backbone Destination Address (B-DA) equal to the original Customer Destination Address (C-DA) of the received customer multicast frames instead of the Default B-DA. This capability may be controlled by an “EnableCustomerMulticast” parameter enabling the above behavior to be independently set for each VIP on the I-component.