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

CX11x, CX31x, CX710 (Earlier Than V6.03), and CX91x Series Switch Modules V100R001C10 Configuration Guide 12

The documents describe the configuration of various services supported by the CX11x&CX31x&CX91x series switch modules The description covers configuration examples and function configurations.
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).
Principles

Principles

This section describes the implementation of PIM.

Concepts

This section describes PIM-related concepts based on the network shown in Figure 8-44.

Figure 8-44 PIM network
Multicast Distribution Tree

On a PIM network, a point-to-multipoint (P2MP) multicast forwarding path is established for each multicast group on separate routers. The multicast forwarding path looks like a tree, so it is also called a multicast distribution tree (MDT).

Two types of MDTs are available:

  • Shortest path tree (SPT): uses the multicast source as the root and multicast group members as leaves.

    In Figure 8-44, the MDT, RouterE→RouterD→RouterA/RouterB, is an SPT, which uses the source as the root and HostA and HostB as leaves.

  • Rendezvous point tree (RPT): uses a rendezvous point (RP) as the root and multicast group members as leaves. RPT applies to PIM-SM or Bidir-PIM networks.

    For details about RP and RPT, see PIM-SM (ASM Model).

    NOTE:

    Leaf hosts of an RPT on a Bidir-PIM network may not only receive multicast data as group members, but also forward multicast data as multicast sources. That is, multicast data is forwarded bidirectionally on the RPT, so the RPT on a Bidir-PIM network is also called a Bidir RPT. For details about Bidir RPT, see Bidir-PIM.

PIM Router

Routers with PIM enabled on interfaces are called PIM routers. During the establishment of an MDT, PIM routers play the following roles:

  • Leaf router: connects to user hosts, which may not be multicast group members. For example, RouterA, RouterB, and RouterC in Figure 8-44 are leaf routers.
  • First-hop router: directly connects to the multicast source on the multicast forwarding path and is responsible for forwarding multicast data from the multicast source. For example, RouterE in Figure 8-44 is the first-hop router.
  • Last-hop router: directly connects to multicast group members (receivers) on the multicast forwarding path and is responsible for forwarding multicast data to these members. For example, RouterA and RouterB in Figure 8-44 are last-hop routers.
  • Intermediate router: resides between the first-hop router and the last-hop router on the multicast forwarding path. For example, RouterD in Figure 8-44 is an intermediate router.
PIM Routing Entry

Two types of PIM routing entries are generated using PIM: (S, G) and (*, G); S indicates a specific multicast source, G indicates a specific multicast group, and * indicates any multicast source.

  • (S, G) entries are often used to establish an SPT on a PIM network. (S, G) entries apply to PIM-SM network.
  • (*, G) entries are often used to establish an RPT on a PIM network. (*, G) entries apply to PIM-SM and Bidir-PIM networks.

A PIM router may have both (S, G) and (*, G) entries. When a PIM router receives a multicast packet with the source address S and the group address G and the packet passes the RPF check, the router forwards the packet according to the following rules:

  • If the (S, G) entry exists, the router forwards the packet according to the (S, G) entry.
  • If the (S, G) entry does not exist but the (*, G) entry exists, the router creates an (S, G) entry based on this (*, G) entry, and then forwards the packet according to the (S, G) entry.

PIM routing entries contain the following information to guide multicast packet forwarding:

  • Multicast source address
  • Multicast group address
  • Upstream interface, which receives multicast data on the local router, such as Int3 in Figure 8-44
  • Downstream interface, which forwards multicast data, such as Int1 and Int2 in Figure 8-44

PIM-SM (ASM Model)

Implementation

In Any-Source Multicast (ASM) implementation, PIM-Sparse Mode (PIM-SM) forwards multicast packets in pull mode and is for use on large-scale networks with sparsely distributed group members. Devices on the PIM-SM network work as follows:

  • A Rendezvous Point (RP), an important PIM router, is available to provide services for group members or multicast sources that appear anytime. All PIM routers on the network know the position of the RP.

  • When a new group member appears on the network (that is, a user host joins a multicast group G through IGMP), the last-hop router sends a Join message to the RP. A (*, G) entry is created hop by hop, and an RPT with the RP as the root is generated.

  • When an active multicast source appears on the network (that is, the multicast source sends the first multicast packet to a multicast group G), the first-hop router encapsulates the multicast data in a Register message and unicasts the Register message to the RP. The RP then creates an (S, G) entry and registers multicast source information.

PIM-SM uses the following mechanisms in the ASM model: neighbor discovery, DR election, RP discovery, RPT setup, multicast source registration, SPT switchover, and assertion. You can also configure a Bootstrap router (BSR) to implement fine-grained management in a single PIM-SM domain. For details about all of these mechanisms, see the sections below.

Neighbor Discovery
PIM routers send Hello messages through PIM-enabled interfaces. In a Hello message:
  • The destination address is 224.0.0.13 and all PIM routers on the same network segment will receive this Hello message.
  • The source address is the IP address of the interface that sends multicast packets.
  • The time to live (TTL) value is 1.

Hello messages are used to discover PIM neighbors, adjust various PIM protocol parameters, and maintain neighbor relationships.

  • Discovering PIM neighbors

    PIM routers on the same network segment must receive multicast packets with the destination address 224.0.0.13. By exchanging Hello messages, directly connected PIM routers learn neighbor information and establish neighbor relationships.

    A PIM router can receive other PIM messages to create multicast routing entries only after it establishes neighbor relationships with other PIM routers.

  • Adjusting PIM protocol parameters

    A Hello message carries the following PIM protocol parameters:

    • DR_Priority: indicates the priority used by router interfaces to elect the designated router (DR). The interface with the highest priority becomes the DR.

    • Holdtime: indicates the period during which a neighbor remains reachable. If a router receives no Hello message from a neighbor within this period, the router considers that the neighbor is unreachable.

    • LAN_Delay: indicates the delay in transmitting Prune messages on a shared network segment.

    • Override-Interval: indicates the interval for overriding the pruning mechanism.

  • Maintaining neighbor relationships

    PIM routers periodically send Hello messages to each other. If a PIM router does not receive a new Hello message from its PIM neighbor within the holdtime, the router considers the neighbor unreachable and deletes the neighbor from the neighbor list.

    Changes of PIM neighbors lead to multicast topology changes on the network. If an upstream or downstream neighbor in the MDT is unreachable, multicast routes re-converge and the MDT is re-established.

DR Election

The network segment where a multicast source or group member resides is usually connected to multiple PIM routers. These PIM routers exchange Hello messages to set up PIM neighbor relationships. The Hello messages carry the DR priority and the interface address of the network segment. Each PIM router compares its own information with the information carried in the messages sent by its neighbors. A DR is then elected for multicast data forwarding on the source side or the receiver side. The election rules are as follows:

  • If all PIM routers on the network segment allow Hello messages to carry DR priorities, the PIM router with the highest DR priority is elected as the DR.

  • If PIM routers have the same DR priority or at least one PIM router does not allow Hello messages to carry the DR priority, the PIM router with the largest IP address is elected as the DR.

If an existing DR becomes faulty, PIM neighbor relationships time out, and a new DR election is triggered among PIM neighbors.

As shown in Figure 8-45, there are two types of DRs in the ASM model:

  • Source DR: DR connected to the multicast source. On the shared network segment connected to the multicast source, the source DR is responsible for sending Register messages to the RP.

  • Receiver DR: DR connected to group members. On the shared network segment connected to group members, the receiver DR is responsible for sending Join messages to the RP.

Figure 8-45 DR election
RP Discovery

An RP is responsible for processing Register messages from the multicast source and Join messages from group members. All PIM routers on the network know the position of the RP.

An RP can serve multiple multicast groups simultaneously, but each multicast group can be associated with only one RP. RPs can be configured either static or dynamic:

  • Static RP: All the PIM routers on the network are manually configured with the same RP address.

  • Dynamic RP: Several PIM routers in the PIM domain are configured as Candidate-RPs (C-RPs) and an RP is elected from the candidates. One or more PIM routers are configured as Candidate-BSRs (C-BSRs). The C-BSRs automatically elect a BSR, and this BSR is responsible for collecting and advertising C-RP information.

    During a BSR election, each C-BSR considers itself the BSR and sends the entire network a BootStrap message that carries its address and priority. Each PIM router compares the Bootstrap messages it receives from the C-BSRs. The BSR is elected based on the result of the comparison:

    • If the C-BSRs have different priorities, the C-BSR with the highest priority (largest priority value) is elected as the BSR.

    • If the C-BSRs have the same priority, the C-BSR with the largest IP address is elected as the BSR.

    Figure 8-46 shows the C-RP election process:

    1. C-RPs send Advertisement messages to the BSR. An Advertisement message carries the address of the C-RP, the range of the multicast groups that it serves, and its priority.

    2. The BSR collects the information in an RP-Set, encapsulates the RP-Set in a Bootstrap message, and advertises the message to each PIM-SM router on the network.

    3. The routers elect an RP from multiple C-RPs that serve a specific multicast group based on the RP-set and the following election rules:
      • If the C-RPs have interface address masks of different lengths, the C-RP with the longest interface address mask is elected as the RP.

      • If the C-RPs have interface address masks of the same length, the C-RP with the highest priority (smallest priority value) is elected.

      • If the C-RPs have the same priority, they use a hash algorithm to calculate their hash values, and the C-RP with the largest hash value is elected as the RP.

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

    4. PIM routers save the relationship between this multicast group and its RP for subsequent multicast operations. This relationships on all PIM routers are the same because they use the same RP-Set and the same election rules.

    Figure 8-46 Dynamic RP election
RPT Setup
Figure 8-47 RPT setup

A PIM-SM RPT is a multicast distribution tree (MDT) that uses an RP as the root and group member routers as leaves. As shown in Figure 8-47, when a group member appears on the network (that is, a user host joins a multicast group G through IGMP), the receiver DR sends a Join message to the RP. A (*, G) entry is created hop by hop, and an RPT with the RP as the root is generated.

During RPT setup, a PIM router performs a reverse path forwarding (RPF) check every time it receives or forwards a Join message. A receiver DR first performs the RPF check: It searches for a unicast route to the RP. The outbound interface of the searched route acts as an upstream interface and the next hop of the searched route acts as an RPF neighbor. Then, the receiver DR sends a Join message to the RPF neighbor. After receiving the Join message, the RPF neighbor performs the RPF check and forwards the Join message upstream at the same time. The Join message is sent upstream hop by hop until it reaches the RP.

Multicast Source Registration
Figure 8-48 Multicast source registration

As shown in Figure 8-48, a new multicast source on the PIM-SM network must register with the RP so that the RP can forward multicast data to group members. The registration and forwarding process is as follows:

  1. The multicast source sends a multicast packet to the source DR.
  2. After receiving the multicast packet, the source DR encapsulates the multicast packet into a Register message and sends the Register message to the RP.
  3. After receiving the Register message, the RP decapsulates it, creates an (S, G) entry, and sends multicast data to group members along the RPT.
SPT Switchover

A multicast group on a PIM-SM network can be associated with only one RP and sets up only one RPT. Under normal circumstances, all multicast packets destined for a multicast group are encapsulated in Register messages and sent to the RP. The RP then decapsulates the packets and forwards them along the RPT to multicast group members. All multicast packets pass through the RP. If the number of multicast packets increases dramatically, the RP becomes heavily burdened. To resolve this problem, PIM-SM allows the RP or the receiver DR to trigger an SPT switchover.

  • SPT switchover triggered by the RP

    After receiving a Register message from the source DR, the RP decapsulates the Register message and forwards multicast packets along the RPT to group members. The RP also sends a Join message to the source DR to set up an SPT from the RP to the source.

    After the SPT is set up, the source DR forwards multicast packets directly to the RP. After the switchover, the source DR and RP do not need to encapsulate or decapsulate packets.

  • SPT switchover triggered by the receiver DR

    Figure 8-49 SPT switchover triggered by the receiver DR

    As shown in Figure 8-49, the receiver DR periodically checks the forwarding rate of multicast packets. When the receiver DR finds that the forwarding rate is higher than a configured threshold, it triggers an SPT switchover.

    1. The receiver DR sends a Join message to the source DR hop by hop, creates an (S, G) entry hop by hop, and then sets up an SPT from the source DR to the receiver DR.
    2. After the SPT is set up, the receiver DR sends Prune messages along the RPT to the RP and deletes the downstream interface connected to it from the (*, G) entry. After the prune action is complete, the RP does not forward multicast packets along the RPT.
    3. Because the SPT does not pass through the RP, the RP continues to send Prune messages along the RPT to the source DR and deletes the downstream interface connected to it from the (S, G) entry. After the prune action is complete, the source DR does not forward multicast packets along the SPT to the RP.
NOTE:

By default, no threshold for the multicast packet forwarding rate is configured on the device. Therefore, an SPT switchover is triggered when the RP or receiver DR receives the first multicast packet from the multicast source.

Assert

When multicast packets pass the RPF check on multiple PIM routers connecting to a network segment, the assert mechanism is required to ensure that only one PIM router forwards the multicast packets to the network segment.

When a PIM router receives a multicast packet that is the same as the multicast packet it sends to other neighbors, the PIM router broadcasts an Assert message with the destination address 224.0.0.13 to all other PIM routers on the same network segment.

When the other PIM routers receive the Assert message, they compare their parameters with those carried in the Assert message for assert election. The election rules are as follows:

  1. If these routers have different priorities, the router with the highest unicast routing priority wins.
  2. If these routers have the same unicast routing priority, the router with the smallest route cost to the multicast source wins.
  3. If these routers have the same unicast routing priority and the same route cost to the multicast source, the router with the highest IP address for the downstream interface wins.

A PIM router performs the following operations based on assert election results:

  • If a router wins the assert election, its downstream interface becomes the assert winner and is responsible for forwarding multicast packets to the shared network segment.

  • If a router fails the assert election, its downstream interface becomes the assert loser, is prohibited from forwarding multicast packets to the shared network segment, and is deleted from the downstream interface list of the (S, G) entry.

After the assert election is complete, only one downstream interface exists on the shared network segment and it transmits only one copy of multicast packets. All assert losers can periodically resume multicast packet forwarding, which causes periodic assert elections.

As shown in Figure 8-50, RouterB and RouterC receive multicast packets from the multicast source. The multicast packets from RouterA pass the RPF check on RouterB and RouterC, RouterB and RouterC create (S, G) entries and send multicast packets to the same network segment that their downstream interfaces connect to.

Figure 8-50 Assert diagram

The assert process is as follows:

  1. RouterB and RouterC receive a multicast packet from each other through a downstream interface, but this packet fails the RPF check and is discarded. Then, RouterB and RouterC send an Assert message to the network segment.

  2. RouterB compares its routing information with that carried in the Assert message sent by RouterC, and it wins the assert election because its route cost to the multicast source is lower than that of RouterC. RouterB then continues to forward subsequent multicast packets to the network segment, whereas RouterC discards subsequent multicast packets because these packets fail the RPF check.

  3. RouterC compares its routing information with that carried in the Assert message sent by RouterB, and it fails the assert election because its route cost to the multicast source is higher than that of RouterB. RouterC then prohibits its downstream interface from forwarding multicast packets to the network segment and deletes the interface from the downstream interface list of the (S, G) entry.

BSR Administrative Domain

To provide fine-grained network management, a PIM-SM network has both a global domain and multiple BSR administrative domains. This reduces the workload on individual BSRs and allows provisioning of special services to users in a specific domain by using private group addresses.

Each BSR administrative domain maintains only one BSR that serves multicast groups within a specific group address range. The global domain maintains a BSR that serves multicast groups not served by an administrative domain.

This section describes the relationship between BSR administrative domains and the global domain in terms of domain space, group address ranges, and multicast functions.

  • Domain space

    Figure 8-51 Relationship between BSR administrative domains and the global domain from in terms of domain space

    As shown in Figure 8-51, BSR administrative domains for the same group address contain different PIM routers. A PIM router belongs to only one BSR administrative domain. BSR administrative domains are independent of and isolated from each other. Each BSR administrative domain manages the multicast groups within a specific group address range. Multicast packets within this range can be transmitted only within this administrative domain and cannot cross its border.

    The global domain contains all PIM routers on the PIM-SM network. A multicast packet that does not belong to any BSR administrative domain can be transmitted throughout the entire PIM network.

  • Group address range

    Figure 8-52 Relationship between BSR administrative domains and the global domain in terms of group address ranges

    Each BSR administrative domain provides services for multicast groups within a specific group address range. The group address ranges served by different BSR administrative domains can overlap. As shown in Figure 8-52, the group address range of BSR1 overlap that of the BSR3. The address of a multicast group that a BSR administrative domain serves is used as a private group address and is valid only in its BSR administrative domain.

    The global domain serves all multicast groups that do not belong to a BSR administrative domain. As shown in Figure 8-52, the group address range of the global domain is G-G1-G2.

  • Multicast function

    As shown in Figure 8-51, the global domain and each BSR administrative domain have their respective C-RP and BSR devices. These devices function only in the domain where they reside. Each domain holds independent BSR and RP elections.

    Each BSR administrative domain has a border. Multicast messages from this domain, such as C-RP Advertisement messages or BSR BootStrap messages, can be transmitted only within the domain where they originate. Multicast messages from the global domain can be transmitted throughout the entire global domain and traverse any BSR administrative domain.

PIM-SM (SSM Model)

Implementation

The SSM model uses IGMPv3/MLDv2 and PIM-SM technology. There is no need to maintain an RP, set up an RPT, or register a multicast source. An SPT can be built directly between the source and group members.

In the SSM model, user hosts know the positions of multicast sources in advance of requesting multicast services. When user hosts join multicast groups, they can specify the sources from which they want to receive data. After receiving requests from user hosts, the receiver DR directly forwards Join messages to the source DR. The Join message is then transmitted upstream hop by hop to set up an SPT between the source and group members.

In the SSM model, PIM-SM uses the following mechanisms: neighbor discovery, DR election, and SPT setup. For details about all of these three mechanisms, see the sections below.

Neighbor Discovery

Neighbor discovery in PIM-SM (SSM model) is similar to that in PIM-SM (ASM model). For details, see "PIM-SM (ASM model) Neighbor Discovery".

DR Election

DR election in PIM-SM (SSM model) is similar to that in PIM-SM (ASM model). For details, see "PIM-SM (ASM model) DR Election".

SPT Setup
Figure 8-53 SPT setup

Figure 8-53 shows the SPT setup process:

  1. Using IGMPv3/MLDv2, RouterD and RouterE learn that packets from user hosts have the same multicast group address but are requesting multicast data from different source addresses. They send Join messages to sources hop by hop.
  2. PIM routers create (S1, G) and (S2, G) entries based on the Join messages and set up SPTs from S1 to HostA and from S2 to HostB.
  3. After SPTs are set up, the sources forward multicast packets along the SPTs to group members.
Comparison with the ASM Model

The major difference between the SSM and ASM models is that the SSM model allows hosts to specify desired multicast sources and the ASM does not. Table 8-30 describes differences of the two models.

Table 8-30 Comparisons between PIM implementations
Protocol Full Name Model Usage Scenario Implementation
PIM-SM Protocol Independent Multicast-Sparse Mode ASM model Large-scale network where multicast group members are distributed sparsely An MDT is set up when receivers join a multicast group. PIM-SM needs to maintain an RP, set up an RPT, and register a multicast source.
SSM model Scenarios where user hosts know the exact positions of multicast sources in advance and can specify the sources from which they want to receive data before they join multicast groups PIM-SSM does not need to maintain an RP, set up an RPT, or register a multicast source.

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 8-54.

Figure 8-54 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 8-54 exchange PIM Hello messages with the Bidirectional Capable PIM-Hello option to set up neighbor relationships and learn about 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 the same as that on a PIM-SM network. All routers obtain RP information after static or dynamic RP configuration is complete. 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 8-55, 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 with each other can be used as RP interfaces and back up each other.

Figure 8-55 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 whole network, ror an RPA, each network segment except the RPL must have a DF elected.

RouterC, RouterD, and RouterF on a shared network segment in Figure 8-54 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 8-54, 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 8-56 shows the DF election process.
Figure 8-56 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 are 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 are 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 8-54.

1. Setting up a bidirectional RPT

Figure 8-57 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 8-57 Bidirectional RPT setup

2. Forwarding multicast data

Figure 8-58 illustrates how multicast data sent from Server and HostC to multicast group G is forwarded on the Bidir-PIM network.
Figure 8-58 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 does 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.

PIM BFD

A network device must detect a communications fault between adjacent devices quickly so that the upper layer protocol can rectify the fault and prevent a service interruption.

Bidirectional Forwarding Detection (BFD) provides uniform, millisecond-level detection for all media and protocol layers. Two systems set up a BFD session and periodically send BFD control packets along the path between them. If one system does not receive BFD control packets within a specified period, the system considers that a fault has occurred on the path.

Implementation

If the current DR or Assert winner on the shared network segment is faulty in a multicast scenario, other PIM neighbors start a new DR election or Assert election after the neighbor relationship or the Assert timer times out. Consequently, multicast data transmission is interrupted. The interruption period, usually in seconds, is at least as long as the timeout interval of the neighbor relationship or the Assert timer.

Because PIM BFD detects the link status on a shared network segment within milliseconds, it responds quickly to PIM neighbor faults. If an interface enabled with PIM BFD does not receive BFD control packets from the DR or Assert winner within the detection interval, it considers that the DR or Assert winner is faulty. BFD fast notifies the RM of the session status and the RM then notifies the PIM module. The PIM module triggers a new DR election or Assert election without waiting for the neighbor relationship or the Assert timer to expire. PIM BFD reduces the time services are interrupted and makes data transmission more reliable.

Figure 8-59 PIM BFD

Figure 8-59 shows a shared network segment connected to user hosts. Downstream Interface1 on RouterB and downstream Interface2 on RouterC establish a PIM BFD session and send BFD control packets to detect link status.

RouterB functions as the DR and its downstream interface Interface1 is responsible for forwarding multicast data. If Interface1 becomes faulty, BFD fast notifies the RM of the session status and the RM then notifies the PIM module. The PIM module then triggers a new DR election. RouterC quickly begins functioning as the new DR and its downstream interface Interface2 forwards multicast data to the receivers.

Translation
Download
Updated: 2019-08-09

Document ID: EDOC1000041694

Views: 59720

Downloads: 3623

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