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

Configuration Guide - IP Multicast

CloudEngine 8800, 7800, 6800, and 5800 V200R005C10

This document describes the configurations of IP multicast, including IP multicast basics, IGMP, MLD, PIM (IPv4), PIM (IPv6), MSDP, multicast VPN, multicast route management (IPv4), multicast route management (IPv6), IGMP snooping, MLD snooping, static multicast MAC address, multicast VLAN, multicast network management.
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).
Bidir-PIM

Bidir-PIM

Implementation

In some multicast applications, such as multi-party video conferencing and online gaming, a user host not only receives multicast data as a receiver, but also sends multicast data to other user hosts as a multicast source. In such a scenario with many multicast sources, if PIM-SM is used to set up shortest path trees (SPTs) for multicast data forwarding, multicast routers must create an (S, G) entry for each multicast source. That is, a multicast group requires a multicast distribution tree for each multicast source. A lot of forwarding resources are consumed to maintain the (S, G) entries, placing heavy burden on the routers.

By all multicast sources for a group sharing the same multicast distribution tree, Bidirectional PIM (Bidir-PIM) can reduce loads on multicast routers. Bidir-PIM sets up a bidirectional rendezvous point tree (RPT) rooted at an RP. Multicast data is forwarded from multicast sources to receivers along the bidirectional RPT. The bidirectional RPT is set up based on (*, G) entries, which means that the multicast distribution tree is built according to the groups while the sources are not in consideration. Routers do not need to maintain a lot of (S, G) entries, consuming much fewer forwarding resources.

Key mechanisms used in Bidir-PIM include neighbor discovery, RP discovery, designated forwarder (DF) election, and bidirectional RPT setup. Bootstrap router (BSR) administrative domains can be configured to implement refined management in a Bidir-PIM domain.

The following sections describe these mechanisms based on the Bidir-PIM network shown in Figure 4-16.

Figure 4-16 Bidir-PIM network

Neighbor Discovery

Like routers on PIM-SM networks, routers on a Bidir-PIM network also exchange PIM Hello messages to maintain neighbor relationships and adjust control parameters for PIM protocol packets. Bidir-PIM adds the Bidirectional Capable PIM-Hello option in PIM Hello messages sent from Bidir-PIM-capable routers.

Routers in Figure 4-16 exchange PIM Hello messages with the Bidirectional Capable PIM-Hello option to set up neighbor relationships and learn the Bidir-PIM capabilities of their neighbors.

For details about the neighbor discovery mechanism, see "PIM-SM (ASM model) Neighbor Discovery".

RP Discovery

The RP discovery mechanism on a Bidir-PIM network is similar to that on a PIM-SM network. All routers obtain RP information after static or dynamic RP configuration is complete. The difference is that Bidir-PIM supports RP election for a multicast group that users have joined based on modulo of the group address and the number of C-RPs. This RP election method can evenly distribute multicast groups to multiple RPs to avoid congestion caused by uneven bandwidth allocation on the Bidir-PIM network. On a Bidir-PIM network, C-RPs select the RP for a multicast group that users have joined according to the following rules:
  • The C-RP with the longest mask length of the served group address range matching the multicast group that users have joined wins.

  • If the mask length is the same, the C-RP with the highest priority (smallest priority value) wins.

  • If the priority is the same, the RP is elected using either of the following rules:
    • C-RPs use the group address that users have joined, C-RP addresses, and C-RP address masks to calculate hash values. The C-RP with the largest hash value becomes the RP that serves the multicast group. This is the default RP election method used on a device, but it cannot evenly distribute multicast groups to RPs and therefore may cause congestion on the multicast network.

    • C-RPs select the RP based on the modulo of the group address that users have joined and the number of C-RPs. This RP election method can evenly distribute multicast groups to RRs to avoid congestion on the multicast network. It is only applicable to networks with multiple C-RPs serving contiguous multicast group addresses.

      This RP election method is applicable to IPv4 Bidir-PIM networks but not IPv6 Bidir-PIM networks.

  • If all the preceding values are the same, the C-RP with the largest IP address wins.

The RP must be configured to serve Bidir-PIM, regardless which configuration method is used.

Bidir-PIM allows a nonexistent rendezvous point address (RPA). That is, the RPA may not be an interface IP address on any router. The network segment to which the RPA belongs is the rendezvous point link (RPL). The RPL must be an existing link connected to a router. Any interface on the RPL can function as the RP interface, and the interfaces back up one other.

In the following description, RPA refers to an RP. An RPA is the transit for multicast data, so it is usually deployed on a link where multicast streams aggregate. In Figure 4-17, the network segment 10.1.1.0/24 connected to RouterA and RouterB is selected as the RPL, and an IP address on this network segment is configured as the RPA. Then the interfaces on RouterA and RouterB connected to each other can be used as RP interfaces and back up each other.

Figure 4-17 Configure an RPA

For details about the RP discovery mechanism, see "PIM-SM (ASM model) RP Discovery".

DF Election

A DF plays an important role on a Bidir-PIM network. It forwards all multicast data on the local network segment, and sends PIM Join messages to the RPA based on requirements of user hosts on the local network segment to set up a bidirectional RPT between the RPA and user hosts.

On the entire network, for an RPA, each network segment except the RPL must have a DF elected.

RouterC, RouterD, and RouterF on a shared network segment in Figure 4-16 are used as an example to describe how a DF is elected.

1. Initial DF election

Once a router obtains RPA information, it triggers a DF election for the RPA on the local network segment by sending multicast Offer messages to the other routers on this network segment. Each Offer message contains the preference and metric of the route from the local router to the RPA. The DF election rules are as follows:
  1. The router with the highest route preference to the RPA wins.
  2. If routers have the same route preference, the one with the smallest route metric to the RPA wins.
  3. If routers have the same route metric to the RPA, the one with the largest interface IP address wins.
On the network shown in Figure 4-16, RouterF has not connected to the local network segment, and RouterC has a smaller route metric to the RPA than RouterD. After RouterC and RouterD obtain RPA information in turn, they start the DF election. Figure 4-18 shows the DF election process.
Figure 4-18 Initial DF election process
  1. RouterC sends an Offer message to the local network segment and starts a timer. The timer value is set to Offer_Period (OP) to control the interval between Offer messages.
  2. RouterD receives the Offer message and finds that the RouterC's route metric to the RPA is smaller than its own metric. Then RouterD enters the offer suppression state and starts a timer, with the timer value set to the product of OP and DF Election_Robustness (ER). During the suppression period, RouterD does not send Offer messages to the local network segment.
  3. RouterC sends an Offer message every time the timer expires, for ER times.
  4. If RouterC does not receive any Offer message from other routers after sending Offer messages ER times, it considers itself the best router on the local network segment. Then RouterC stops the timer and sends Win messages to the local network segment to announce itself as the DF.
  5. When RouterD receives a Win message, it records DF information in the Win message and enters the Lose state.

2. DF election upon a network topology change

After the initial DF election, RouterC becomes the DF on the shared network segment. DF elections are not performed periodically, and RouterC retains the DF role as long as the network topology remains unchanged. When the network topology changes, different DF election processes are triggered in different conditions as follows:

  • The Loser's route metric to the RPA changes: RouterD's route metric to the RPA becomes smaller than that of RouterC.



    1. RouterD compares recorded DF information with its own information and finds that its own route metric is smaller than the DF's route metric to the RPA. Therefore, RouterD sends an Offer message to the local network segment and starts a timer, with the timer value set to OP.
    2. When RouterC receives the Offer message, it knows that RouterD has a smaller route metric to the RPA. Then it sends a Backoff message to the local network segment to announce that a router with a better route to the RPA is available. At the same time, RouterC starts a timer and sets the timer value to Backoff_Period (BP) to control the interval between Backoff messages.
    3. When RouterD receives the Backoff message, it finds that the message carries its own information. RouterD then enters the Offer suppression state and resets its timer to BP + OP.
    4. When the timer of RouterC times out, RouterC sends a Pass message to announce RouterD as the new DF. Meanwhile, RouterC enters the Lose state and records the new DF information.
    5. When RouterD receives the Pass message, it stops its timer, enters the Win state, and becomes the new DF.
  • The DF's route metric to the RPA changes: RouterC's route metric to the RPA becomes larger than that of RouterD.

    1. When RouterC finds that its route metric to the RPA increases, it sends a Win message to the local network segment.
    2. When RouterD receives the Win message, it finds that its own route metric is smaller and sends an Offer message to the local network segment. The subsequent process is the same as that occurs when the Loser's route metric to the RPA changes.
  • The DF loses the route to the RPA: RouterC has no reachable route to the RPA.

    1. RouterC no longer works as the DF and sends an Offer message with an infinite metric value to the RPA.
    2. When RouterD receives the Offer message, it finds that its own route metric is smaller and sends an Offer message to the local network segment. The subsequent process is the same as the initial DF election process.
  • A new router appears: RouterF joins the local network segment and has a larger route metric to the RPA than RouterC and RouterD.

    1. RouterF sends an Offer message to the local network segment.
    2. When RouterD receives the Offer message, it finds that its own route metric to the RPA is smaller. Then RouterD enters the suppression state and starts a timer, with the timer value set to OP. In suppression state, RouterD waits for the message sent by the DF in response to RouterF's Offer message and does not send Offer messages.
    3. When RouterC receives the Offer message, it finds that is own route metric to the RPA is smaller and sends a Win message to the local network segment.
    4. When RouterF receives the Win message, it enters the Lose state and records DF information.
    5. When RouterD receives the Win message, it enters the Lose state and records DF information.
  • The DF stops working: RouterC fails.

    RouterD receives no PIM Hello message from RouterC in a long time and considers that its PIM neighbor has failed. It then sends an Offer message to the local network segment. The subsequent DF election process is the same as the initial DF election process.

Bidirectional RPT Setup

A bidirectional RPT forwards multicast data bidirectionally. When a host requests data sent to multicast group G, the routers connected to the host send PIM Join messages hop by hop toward the RPA. Based on the PIM Join messages, the routers create (*, G) entries to set up an RPT. The RPT setup process stops on the RPL. The Bidir-PIM protocol considers the host as both a receiver and a multicast source for group G. Therefore, the routers add both the DF interface and the reverse path forwarding (RPF) interface toward the RPA to the outbound interface list in their (*, G) entries. In this way, a bidirectional RPT is set up based on the (*, G) entries.

Note that multicast data sent from a multicast source is still forwarded unidirectionally. Bidirectional mentioned in this section means that multicast data sent from different multicast sources is forwarded in different directions. When routers on a bidirectional RPT receive a multicast data packet, they check whether the inbound interface of the packet is the RPF or DF interface. If so, the routers forward the packet according to the (*, G) entry. If not, they drop the packet. The routers never forward a multicast data packet to the inbound interface of the packet, even if the inbound interface is in the outbound interface list of the (*, G) entry. Therefore, multicast data sent from a host is forwarded unidirectionally on the bidirectional RPT and will not be sent back to the host.

If multicast data is only sent from multicast sources and hosts only receive multicast data, a bidirectional RPT cannot be set up. In this case, multicast data sent from multicast sources is unconditionally forwarded to the RPA by the DF.

The following describes the bidirectional RPT setup and multicast data forwarding processes for HostA, HostC, and Server on Figure 4-16.

1. Setting up a bidirectional RPT

Figure 4-19 shows the bidirectional RPT setup process triggered by HostC as a receiver, which is described as follows:
  1. HostC sends an IGMP Report message. Interface IF0 of RouterF is the DF on the local network segment. When IF0 receives the IGMP Report message, RouterF creates a (*, G) entry and adds IF0 and the RPF interface (IF1) toward the RPA to the outbound interface list. Meanwhile, RouterF sends a PIM Join message to IF1, which forwards the PIM Join message to the upstream neighbor, the DF on the network segment connected to IF1.
  2. When RouterC receives the PIM Join message from DF interface IC0, it creates a (*, G) entry, and adds IC0 and the RPF interface IC1 toward the RPA to the outbound interface list. Meanwhile, RouterC sends a PIM Join message to IC1, which forwards the PIM Join message to the upstream neighbor, the DF on the network segment connected to IC1.
  3. When RouterA receives the PIM Join message from DF interface IA1, it creates a (*, G) entry, and adds IA1, DF interface IA0 on the network segment of HostA, and RPF interface IA2 toward the RPA to the outbound interface list. The bidirectional RPT setup process ends on RouterA because RouterA is directly connected to the RPL.
The bidirectional RPT setup process triggered by HostA is similar.
Figure 4-19 Bidirectional RPT setup

2. Forwarding multicast data

Figure 4-20 illustrates how multicast data sent from Server and HostC to multicast group G is forwarded on the Bidir-PIM network.
Figure 4-20 Multicast data packet forwarding

  • Forwarding of multicast data sent from HostC:
    1. HostC sends multicast data packets. RouterF receives the multicast data packets from DF interface IF0 and forwards them to outbound interface IF1 according to the matching (*, G) entry. RouterF does not forward the multicast data packets to IF0 in the outbound interface list, because IF0 is the inbound interface of the multicast data packets.
    2. RouterC receives the multicast data packets from DF interface IC0 and forwards them to outbound interface IC1 according to the matching (*, G) entry. RouterC does not forward the multicast data packets to IC0 in the outbound interface list, because IC0 is the inbound interface of the multicast data packets.
    3. RouterA receives the multicast data packets from DF interface IA0 and forwards them to outbound interfaces IA1 and IA2 according to the matching (*, G) entry. RouterA does not forward the multicast data packets to IA0 in the outbound interface list, because IA0 is the inbound interface of the multicast data packets.
    4. RouterB receives the multicast data packets from interface IB1 and finds no matching (*, G) entry for the packets. Because the RPF interface IB1 toward the RPA is the inbound interface of the multicast data packets, RouterB stops forwarding the multicast data packets.
    5. HostA receives the multicast data packets, and multicast data forwarding is complete.
  • Forwarding of multicast data sent from Server:
    1. Server sends multicast data packets. RouterE receives the multicast data packets from DF interface IE0 and finds no matching (*, G) entry for the packets. Therefore, RouterE forwards the multicast data packets to RPF interface IE1 toward the RPA.
    2. RouterB receives the multicast data packets from DF interface IB0 and finds no matching (*, G) entry for the packets. Therefore, RouterB forwards the multicast data packets to RPF interface IB1 toward the RPA.
    3. RouterA receives the multicast data packets and forwards them to outbound interfaces IA0 and IA1 according to the matching (*, G) entry. RouterA does not forward the multicast data packets to IA2 in the outbound interface list, because IA2 is the inbound interface of the multicast data packets.
    4. HostA receives the multicast data packets.
    5. RouterC receives the multicast data packets from RPF interface IC1 and forwards them to outbound interface IC0 according to the matching (*, G) entry. RouterC does not forward the multicast data packets to IC1 in the outbound interface list, because IC1 is the inbound interface of the multicast data packets.
    6. RouterF receives the multicast data packets from RPF interface IF1 and forwards them to outbound interface IF0 according to the matching (*, G) entry. RouterF does not forward the multicast data packets to IF1 in the outbound interface list, because IF1 is the inbound interface of the multicast data packets.
    7. HostC receives the multicast data packets. Multicast data forwarding is complete.

BSR Administrative Domain

To provide fine-grained network management, a Bidir-PIM network can be divided into a global domain and multiple BSR administrative domains. This reduces the workload on a single BSR and allows provisioning of services specific to a domain using private group addresses.

The BSR administrative domain mechanism on a Bidir-PIM network is the same as that on a PIM-SM network. For details, see PIM-SM (ASM model) BSR Administrative Domain.

Translation
Download
Updated: 2019-04-20

Document ID: EDOC1100075361

Views: 29632

Downloads: 34

Average rating:
This Document Applies to these Products
Related Documents
Related Version
Share
Previous Next