No relevant resource is found in the selected language.

This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Read our privacy policy>Search

Reminder

To have a better experience, please upgrade your IE browser.

upgrade

NE20E-S V800R010C10SPC500 Feature Description - IP Multicast 01

This is NE20E-S V800R010C10SPC500 Feature Description - IP Multicast

Rate and give feedback:
Huawei uses machine translation combined with human proofreading to translate this document to different languages in order to help you better understand the content of this document. Note: Even the most advanced machine translation cannot match the quality of professional translators. Huawei shall not bear any responsibility for translation accuracy and it is recommended that you refer to the English document (a link for which has been provided).
NG MVPN Private Multicast Routing

NG MVPN Private Multicast Routing

The networks on the two sides of NG MVPN are one for the multicast source while the other for multicast users, namely, the VPN on the multicast source side and the VPN on the user side. The two networks connect to the public network separately through the sender PE and receiver PE.
  • The multicast source can be registered by the directly connected multicast source DR to the RP, or receive the Join message sent by the receiver DR, so as to send multicast data to the receiver. For details about multicast source registration, see PIM-SM and PIM-SSM.
  • A multicast user joins a multicast group through IGMP/MLD, and then the multicast device to which the multicast group belongs sends a Join message to the multicast source through PIM. In this manner, the multicast user can receive multicast data. For details about how multicast users join multicast groups on VPNs, see IGMP and MLD.

On an NG MVPN, after a BGP peer relationship is established between PEs in the BGP MVPN address family, the BGP MVPN extended community attribute can be used to carry the VPN multicast route (C-multicast route) to transmit the join/leave information of multicast users.

MVPN Extended Community Attributes

MVPN extended community attributes, which are used to control the advertisement and receiving of BGP C-multicast routes, can be:
  • Source AS Extended Community: carried in VPNv4 routes advertised by PEs. This attribute is an AS extended community attribute and is mainly used in inter-AS scenarios.

  • VRF Route Import Extended Community: carried in VPNv4 routes advertised by sender PEs to receiver PEs. When a receiver PE sends a BGP C-multicast route to a sender PE, the receiver PE attaches this attribute to the route. In a scenario in which many sender PEs exist, this attribute helps a sender PE that receives the BGP C-multicast route to determine whether to process the route and to which VPN instance routing table the BGP C-multicast route should be added.

    The value of the VRF Route Import Extended Community is in the format of "Administrator field value:Local Administrator field value". The Administrator field is set to the local MVPN ID, whereas the Local Administrator field is set to the local VPN instance ID of the sender PE.

    On the network shown in Figure 8-13, PE1 and PE2 are both sender PEs, and PE3 is a receiver PE. PE1 and PE2 connect to both vpn1 and vpn2. On PE1, the VRF Route Import Extended Community is 1.1.1.9:1 for vpn1 and 1.1.1.9:2 for vpn2; on PE2, the VRF Route Import Extended Community is 2.2.2.9:1 for vpn1 and 2.2.2.9:2 for vpn2.

    After PE1 and PE2 both establish BGP MVPN peer relationships with PE3, PE1 and PE2 both send to PE3 a VPNv4 route destined for the multicast source 192.168.1.2. The VRF Route Import Extended Community carried in the VPNv4 route sent by PE1 is 1.1.1.9:1 and that carried in the VPNv4 route sent by PE2 is 2.2.2.9:1. After PE3 receives the two VPNv4 routes, PE3 adds the preferred route (VPNv4 route sent by PE1 in this example) to the vpn1 routing table and stores the VRF Route Import Extended Community value carried in the preferred route locally for later BGP C-multicast route generation.

    Upon receipt of a PIM Join message from CE3, PE3 generates a BGP C-multicast route with the RT-import attribute and sends this route to PE1 and PE2. The RT-import attribute value of this route is the same as the locally stored VRF Route Import Extended Community value, 1.1.1.9:1. Then,
    • Upon receipt of the BGP C-multicast route, PE1 checks the RT-import attribute of this route. After PE1 finds that the Administrator field value is 1.1.1.9, which is the same as its local MVPN ID, PE1 accepts this route and adds it to the vpn1 routing table based on the Local Administrator field value, 1.
    • Upon receipt of the BGP C-multicast route, PE2 also checks the RT-import attribute of this route. After PE2 finds that the Administrator field value is 1.1.1.9, a value different from its local MVPN ID 2.2.2.9, PE2 drops this route.
    Figure 8-13 Application of the VRF Route Import Extended Community

This section describes the process of transmitting VPN multicast routes through the (S, G) and (*, G) Join/Leave processes of multicast members.

PIM (S, G) Join/Prune

Multicast receiver joins/leaves a multicast group in PIM (S, G) modes.

On the network shown in Figure 8-14, CE1 connects to the multicast source, and CE2 connects multicast receivers. CE2 sends PIM (S, G) Join/Prune messages to CE1. This process shows how a multicast member joins and leaves a multicast group.

Figure 8-14 NG MVPN

Figure 8-15 Time sequences for joining a multicast group

Figure 8-15 shows the procedure for joining a multicast group, and Table 8-12 describes this procedure.

Table 8-12 Procedure for joining a multicast group

Step

Device

Key Action

PE1

After PE1 receives a unicast route destined for the multicast source from CE1, PE1 converts this route to a VPNv4 route, adds the Source AS Extended Community and VRF Route Import Extended Community to this route, and advertises this route to PE2.

For more information about the Source AS Extended Community and VRF Route Import Extended Community, see MVPN Extended Community Attributes.

PE2

After PE2 receives the VPNv4 route from PE1, PE2 matches the export VPN target of the route against its local import VPN target:
  • If the two targets match, PE2 accepts the VPNv4 route and stores the Source AS Extended Community and VRF Route Import Extended Community values carried in this route locally for later generation of the BGP C-multicast route.
  • If the two targets do not match, PE2 drops the VPNv4 route.

CE2

After CE2 receives an IGMP join request, CE2 sends a PIM-SSM Join message to PE2.

PE2

After PE2 receives the PIM-SSM Join message:
  • PE2 generates a multicast entry. In this entry, the downstream interface is the interface that receives the PIM-SSM Join message and the upstream interface is the P2MP tunnel interface on the path to the multicast source.
  • PE2 generates a BGP C-multicast route based on the locally stored Source AS Extended Community and VRF Route Import Extended Community values. The RT-import attribute of this route is set to the locally stored VRF Route Import Extended Community value.
    NOTE:
    In the BGP route with MVPN information, the NLRI field is called MVPN NLRI. The routes whose Route type value is 6 or 7 are C-multicast routes. For more information about C-multicast route structure, see MVPN NLRI.

PE2

PE2 sends the BGP C-multicast route to PE1.

PE1

After PE1 receives the BGP C-multicast route:
  1. PE1 checks the Administrator field and Local Administrator field values in the RT-import attribute of the BGP C-multicast route. After PE1 confirms that the Administrator field value is its MVPN ID, PE1 accepts the BGP C-multicast route.
  2. PE1 determines to which VPN instance routing table should the BGP C-multicast route be added based on the Local Administrator field value in the RT-import attribute of the route.
  3. PE1 adds the BGP C-multicast route to the corresponding VPN instance routing table and creates a VPN multicast entry to guide multicast traffic forwarding. In the multicast entry, the downstream interface is PE1's P2MP tunnel interface.
  4. PE1 converts the BGP C-multicast route to a PIM-SSM Join message.

PE1

PE1 sends the PIM-SSM Join message to CE1.

CE1

After CE1 receives the PIM-SSM Join message, CE1 generates a multicast entry. In this entry, the downstream interface is the interface that receives the PIM-SSM Join message. After that, the multicast receiver successfully joins the multicast group, and CE1 can send multicast traffic to CE2.

Figure 8-16 Time sequence for leaving a multicast group

Figure 8-16 shows the procedure for leaving a multicast group, and Table 8-13 describes this procedure.

Table 8-13 Procedure for leaving a multicast group

Step

Device

Key Action

CE2

CE2 detects that a multicast receiver attached to itself leaves the multicast group.

PE2

PE2 deletes the corresponding multicast entry after this entry ages out. Then, PE2 generates a BGP Withdraw message.

PE2

PE2 sends the BGP Withdraw message to PE1.

PE1

After PE1 receives the BGP Withdraw message, PE1 deletes the corresponding multicast entry and generates a PIM-SSM Prune message.

PE1

PE1 sends the PIM-SSM Prune message to CE1.

CE1

After CE1 receives the PIM-SSM Prune message, CE1 stops sending multicast traffic to CE2.

PIM (*, G) Join/Prune

Multicast receiver joins/leaves a multicast group in PIM (*, G) modes.

Table 8-14 lists the implementation modes of PIM (*, G) multicast joining and leaving.

Table 8-14 Implementation modes of PIM (*, G) multicast joining and leaving

Implementation Mode

Principle

Advantage

Disadvantage

Across the public network
PIM (*, G) entries are transmitted across the public network to remote PEs. The multicast joining process includes:
  • Rendezvous point tree (RPT) construction (see Table 8-15 for more information)
  • Switching from an RPT to a shortest path tree (SPT) (see Table 8-16 for more information)

The private network rendezvous point (RP) can be deployed at either a CE or a PE.

  • The RPT-to-SPT switching may occur on the public network, so PEs need to maintain a lot of route state information.
  • Currently, a private network RP must be a static RP.
Not across the public network

PIM (*, G) entries are converted to PIM (S, G) entries before being transmitted to remote PEs across the public network.

  • PIM (*, G) entries are not transmitted across the public network, lowering the performance requirements for PEs.
  • The private network RP can be either a static RP or a dynamic RP.

The private network RP can be deployed on either a PE or a CE. If a CE serves as the private network RP, the CE must establish an MSDP peer relationship with the corresponding PE.

NOTE:

The advertisement of VPNv4 routes during multicast joining and leaving in PIM (*, G) mode is similar to that in PIM (S, G) mode. For more information, see PIM (S, G) Join/Prune.

PIM (*, G) multicast joining and leaving across the public network

On the network show in Figure 8-17, CE3 serves as the RP. Figure 8-18 shows the time sequence for establishing an RPT.

Figure 8-17 Networking for PIM (*, G) multicast joining and leaving
Figure 8-18 Time sequence for establishing an RPT

Table 8-15 describes the procedure for establishing an RPT.

Table 8-15 Procedure for establishing an RPT

Step

Device

Key Action

CE2

After CE2 receives an IGMP join request, CE2 sends a PIM (*, G) Join message to PE2.

PE2

After PE2 receives the PIM (*, G) Join message: PE2 generates a PIM (*, G) entry. In this entry, the downstream interface is the interface that receives the PIM (*, G) Join message and the upstream interface is the P2MP tunnel interface on the path to the RP. In this case, the upstream interface is the interface used by PE3 to connect to PE2. PE2 generates a BGP C-multicast route (Shared Tree Join route) based on the locally stored Source AS Extended Community and VRF Route Import Extended Community values. The RT-import attribute of this route is set to the locally stored VRF Route Import Extended Community value. PE2 sends the BGP C-multicast route to PE3, its BGP peer.

NOTE:
For more information about BGP C-multicast route generation, see MVPN NLRI.

PE3

After PE3 receives the BGP C-multicast route (Shared Tree Join route):
  1. PE3 checks the Administrator field and Local Administrator field values in the RT-import attribute of the BGP C-multicast route. After PE3 confirms that the Administrator field value is the same as its local MVPN ID, PE3 accepts the BGP C-multicast route.
  2. PE3 determines to which VPN instance routing table should the BGP C-multicast route be added based on the Local Administrator field value in the RT-import attribute of the route.
  3. PE3 adds the BGP C-multicast route to the corresponding VPN instance routing table and creates a VPN multicast entry to guide multicast traffic forwarding. In the multicast entry, the downstream interface is PE3's P2MP tunnel interface.
  4. PE3 converts the BGP C-multicast route to a PIM (*, G) Join message and sends this message to CE3.

CE3

Upon receipt of the PIM (*, G) Join message, CE3 generates a PIM (*, G) entry. In this entry, the downstream interface is the interface that receives the PIM (*, G) Join message. Then, an RPT rooted at CE3 and with CE2 as the leaf node is established.

CE1

After CE1 receives multicast traffic from the multicast source, CE1 sends a PIM Register message to CE3.

CE3

Upon receipt of the PIM Register message, CE3 generates a PIM (S, G) entry, which inherits the outbound interface of the previously generated PIM (*, G) entry. Meanwhile, CE3 sends multicast traffic to PE3.

PE3

Upon receipt of the multicast traffic, PE3 generates a PIM (S, G) entry, which inherits the outbound interface of the previously generated PIM (*, G) entry. Because the outbound interface of the PIM (*, G) entry is a P2MP tunnel interface, multicast traffic is imported to the I-PMSI tunnel.

PE2

Upon receipt of the multicast traffic, PE2 generates a PIM (S, G) entry, which inherits the outbound interface of the previously generated PIM (*, G) entry.

CE2

Upon receipt of the multicast traffic, CE2 sends the multicast traffic to multicast receivers.

When the multicast traffic sent by the multicast source exceeds the threshold set on set, CE2 initiates RPT-to-SPT switching. Figure 8-19 shows the time sequence for switching an RPT to an SPT.

NOTE:
When the receiver PE receives multicast traffic transmitted along the RPT, the receiver PE immediately initiates RPT-to-SPT switching. The RPT-to-SPT switching process on the receiver PE is similar to that on CE2.
Figure 8-19 Time sequence for RPT-to-SPT switching

Table 8-16 describes the procedure for switching an RPT to an SPT.

Table 8-16 Procedure for RPT-to-SPT switching

Step

Device

Key Action

CE2

After the received multicast traffic exceeds the set threshold, CE2 initiates RPT-to-SPT switching by sending a PIM (S, G) Join message to PE2.

PE2

Upon receipt of the PIM (S, G) Join message, PE2 updates the outbound interface status in its PIM (S, G) entry, and switches the PIM (S, G) entry to the SPT. Then, PE2 searches its multicast routing table for a route to the multicast source. After PE2 finds that the upstream device on the path to the multicast source is PE1, PE2 sends a BGP C-multicast route (Source Tree Join route) to PE1.

PE1

Upon receipt of the BGP C-multicast route (Source Tree Join route), PE1 generates a PIM (S, G) entry, and sends a PIM (S, G) Join message to CE1.

CE1

Upon receipt of the PIM (S, G) Join message, CE1 generates a PIM (S, G) entry. Then, the RPT-to-SPT switching is complete and CE1 can send multicast traffic to PE1.

PE1

To prevent duplicate multicast traffic, PE1 carries the PIM (S, G) entry information in a Source Active AD route and sends the route to all its BGP peers.

PE3

Upon receipt of the Source Active AD route, PE3 records the route. After RPT-to-SPT switching, PE3, the ingress of the P2MP tunnel for the RPT, deletes received multicast traffic, generates the (S, G, RPT) state, and sends a PIM (S, G, RPT) Prune to its upstream. Meanwhile, PE3 updates its VPN multicast routing entries and stops forwarding multicast traffic.

NOTE:
To prevent packet loss during RPT-to-SPT switching, the PIM (S, G, RPT) Prune operation is performed after a short delay.

PE2

Upon receipt of the Source Active AD route, PE2 records the route. Because the Source Active AD route carries information about the PIM (S, G) entry for the RPT, PE2 initiates RPT-to-SPT switching. After PE2 sends a BGP C-multicast route (Source Tree Join route) to PE1, PE2 can receive multicast traffic from PE1.

Figure 8-20 shows the time sequence for leaving a multicast group in PIM (*, G) mode.

Figure 8-20 Time sequence for leaving a multicast group in PIM (*, G) mode

Table 8-17 describes the procedure for leaving a multicast group in PIM (*, G) mode.

Table 8-17 Procedure for leaving a multicast group in PIM (*, G) mode

Step

Device

Key Action

CE2

After CE2 detects that a multicast receiver attached to itself leaves the multicast group, CE2 sends a PIM (*, G) Prune message to PE2. If CE2 has switched to the SPT, CE2 also sends a PIM (S, G) Prune message to PE2.

PE2

Upon receipt of the PIM (*, G) Prune message, PE2 deletes the corresponding PIM (*, G) entry. Upon receipt of the PIM (S, G) Prune message, PE2 deletes the corresponding PIM (S, G) entry.

PE2

PE2 sends a BGP Withdraw message (Shared Tree Join route) to PE3 and a BGP Withdraw message (Source Tree Join route) to PE1.

PE1

Upon receipt of the BGP Withdraw message (Source Tree Join route), PE1 deletes the previously recorded BGP C-multicast route (Source Tree Join route) as well as the outbound interface in the PIM (S, G) entry.

PE3

Upon receipt of the BGP Withdraw message (Shared Tree Join route), PE3 deletes the previously recorded BGP C-multicast route (Shared Tree Join route) as well as the outbound interface in the PIM (S, G) entry.

PIM (*, G) multicast joining and leaving not across the public network

On the network show in Figure 8-17, each site of the MVPN is a PIM-SM BSR domain. A PE serves as the RP. Figure 8-21 shows the time sequence for joining a multicast group when a PE serves as the RP.

Figure 8-21 Time sequence for joining a multicast group when a PE serves as the RP

Table 8-18 describes the procedure for joining a multicast group when a PE serves as the RP.

Table 8-18 Procedure for joining a multicast group when a PE serves as the RP

Step

Device

Key Action

CE2

After CE2 receives an IGMP join request, CE2 sends a PIM (*, G) Join message to PE2.

PE2

Upon receipt of the PIM (*, G) Join message, PE2 generates a PIM (*, G) entry. Because PE2 is the RP, PE2 does not send the BGP C-multicast route (Shared Tree Join route) to other devices. Then, an RPT rooted at PE2 and with CE2 as the leaf node is established.

CE1

After CE1 receives multicast traffic from the multicast server, CE1 sends a PIM Register message to PE1.

PE1

Upon receipt of the PIM Register message, PE1 generates a PIM (S, G) entry.

PE1

PE1 sends a Source Active AD route to all its BGP peers.

PE2

Upon receipt of the Source Active AD route, PE2 generates a PIM (S, G) entry, which inherits the outbound interface of the previously generated PIM (*, G) entry.

PE2

PE2 initiates RPT-to-SPT switching and sends a BGP C-multicast route (Source Tree Join route) to PE1.

PE1

Upon receipt of the BGP C-multicast route (Source Tree Join route), PE1 imports multicast traffic to the I-PMSI tunnel based on the corresponding VPN multicast forwarding entry. Then, multicast traffic is transmitted over the I-PMSI tunnel to CE2.

Figure 8-22 shows the time sequence for leaving a multicast group when a PE serves as the RP.

Figure 8-22 Time sequence for leaving a multicast group when a PE serves as the RP

Table 8-19 describes the procedure for leaving a multicast group when a PE serves as the RP.

Table 8-19 Procedure for leaving a multicast group when a PE serves as the RP

Step

Device

Key Action

CE2

After CE2 detects that a multicast receiver attached to itself leaves the multicast group, CE2 sends a PIM (*, G) Prune message to PE2.

PE2

Upon receipt of the PIM (*, G) Prune message, PE2 deletes the corresponding PIM (*, G) entry.

CE2

CE2 sends a PIM (S, G) Prune message to PE2.

PE2

Upon receipt of the PIM (S, G) Prune message, PE2 deletes the corresponding PIM (S, G) entry. PE2 sends a BGP Withdraw message (Source Tree Join route) to PE1.

PE1

Upon receipt of the BGP Withdraw message (Source Tree Join route), PE1 deletes the previously recorded BGP C-multicast route (Source Tree Join route) as well as the outbound interface in the PIM (S, G) entry. Meanwhile, PE1 sends a PIM (S, G) Prune message to CE1.

CE1

Upon receipt of the PIM (S, G) Prune message, CE1 stops sending multicast traffic to CE2.

On the network show in Figure 8-17, each site of the MVPN is a PIM-SM BSR domain. A CE serves as the RP. CE3 has established an MSDP peer relationship with PE3, and PE2 has established an MSDP peer relationship with CE2. Figure 8-23 shows the time sequence for joining a multicast group when a CE serves as the RP.

Figure 8-23 Time sequence for joining a multicast group when a CE serves as the RP

Table 8-20 describes the procedure for joining a multicast group when a CE serves as the RP.

Table 8-20 Procedure for joining a multicast group when a CE serves as the RP

Step

Device

Key Action

CE2

After CE2 receives an IGMP join request, CE2 generates a PIM (*, G) Join message. Because CE2 is the RP, CE2 does not send the PIM (*, G) Join message to its upstream.

CE1

After CE1 receives multicast traffic from the multicast server, CE1 sends a PIM Register message to CE3.

CE3

Upon receipt of the PIM Register message, CE3 generates a PIM (S, G) entry.

CE3

CE3 carries the PIM (S, G) entry information in an MSDP Source Active (SA) message and sends the message to its MSDP peer, PE3.

PE3

Upon receipt of the MSDP SA message, PE3 generates a PIM (S, G) entry.

PE3

PE3 carries the PIM (S, G) entry information in a Source Active AD route and sends the route to other PEs.

PE2

Upon receipt of the Source Active AD route, PE2 learns the PIM (S, G) entry information carried in the route. Then, PE2 sends an MSDP SA message to transmit the PIM (S, G) entry information to its MSDP peer, CE2.

CE2

Upon receipt of the MSDP SA message, CE2 learns the PIM (S, G) entry information carried in the message and generates a PIM (S, G) entry. Then, CE2 initiates a PIM (S, G) join request to the multicast source. Finally, CE2 forwards the multicast traffic to multicast receivers.

Figure 8-24 shows the time sequence for leaving a multicast group when a CE serves as the RP.

Figure 8-24 Time sequence for leaving a multicast group when a CE serves as the RP

Table 8-21 describes the procedure for leaving a multicast group when a CE serves as the RP.

Table 8-21 Procedure for leaving a multicast group when a CE serves as the RP

Step

Device

Key Action

CE2

After CE2 detects that a multicast receiver attached to itself leaves the multicast group, CE2 generates a PIM (*, G) Prune message. Because CE2 is the RP, CE2 does not send the PIM (*, G) Prune message to its upstream.

CE2

CE2 sends a PIM (S, G) Prune message to PE2.

PE2

Upon receipt of the PIM (S, G) Prune message, PE2 deletes the corresponding PIM (S, G) entry. Then, PE2 sends a BGP Withdraw message (Shared Tree Join route) to PE1.

PE1

Upon receipt of the BGP Withdraw message (Source Tree Join route), PE1 deletes the previously recorded BGP C-multicast route (Source Tree Join route) as well as the outbound interface in the PIM (S, G) entry. Meanwhile, PE1 sends a PIM (S, G) Prune message to CE1.

CE1

Upon receipt of the PIM (S, G) Prune message, CE1 stops sending multicast traffic to CE2.

Translation
Download
Updated: 2019-01-03

Document ID: EDOC1100055119

Views: 15534

Downloads: 22

Average rating:
This Document Applies to these Products

Related Version

Related Documents

Share
Previous Next