Anycast RP Network Device for Multicast Source Identity Learning
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Conventional MVPN extranets using any-source multicast (ASM) often fail to allow client VRFs to receive multicast traffic from a service VRF, as the ASM rendezvous point is provisioned within the client VRF, preventing the learning of the multicast source identity.
Innovation Solution
Configuring network devices with anycast RP addresses to enable the service and client routing elements to exchange register messages, allowing the client routing elements to learn the multicast source identity and replicate the register message within their respective domains, ensuring proper multicast traffic reception.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If an ASM rendezvous point (RP) is provisioned within the client VRF, then the client VRF can support any-source multicast, but the client VRF and its associated CE elements will be unable to receive multicast traffic from a service VRF
Solution Approach 1:
The service routing element acts as an intermediary by receiving register messages from service VRF sources and forwarding them to client routing elements. This mediator function allows client VRFs to learn source identities without requiring the RP to be directly provisioned within the client VRF, thus resolving the contradiction between ASM support and traffic reception capability
Solution Approach 2:
The system segments the multicast routing function into service routing elements and client routing elements operating in separate domains. The service routing element handles service VRF multicast traffic and learns source identities, then shares this information with client routing elements. This segmentation allows each element to operate independently while maintaining overall system functionality
2Loss of information
If the service routing element shares source identity information with the client routing element, then the client routing element can learn the multicast source identity, but additional message forwarding and processing is required
Solution Approach 1:
The register message is designed to serve multiple functions: it carries source identity information, triggers (*,G) join message generation, and enables client routing elements to learn source identities. This multi-functionality reduces the need for separate mechanisms, thereby limiting the increase in device complexity while achieving comprehensive source identity learning
Data Source
Figure 1
Figure 2
Figure 3
AI summary
A first network device comprises a service routing element and a client routing element. The service routing element is configured with a first anycast rendezvous point address so as be an anycast rendezvous point peer with at least a second network device in a service routing domain. The client routing element is configured with a second anycast rendezvous point address so as to be an anycast rendezvous point peer with at least a third network device in a client routing domain. The first network device receives in its service routing element from a service routing element of the second network device a register message identifying a multicast source, and provides at least a portion of the register message from its service routing element to its client routing element in a manner that allows the third network device to learn the identity of the multicast source from the client routing element.