Protocol Independent Multicast (PIM) nonbroadcast multiaccess (NBMA) mode allows the software to replicate packets for each neighbor on the NBMA network. Traditionally, the software replicates multicast and broadcast packets to all broadcast configured neighbors. This action might be inefficient when not all neighbors want packets for certain multicast groups. NBMA mode enables you to reduce bandwidth on links leading into the NBMA network, and to reduce the number of CPU cycles in switches and attached neighbors.

It is appropriate to configure PIM NBMA mode on ATM, Frame Relay, Switched Multimegabit Data Service (SMDS), PRI ISDN, or X.25 networks only, especially when these media do not have native multicast available. Do not use PIM NBMA mode on multicast-capable LANs (such as Ethernet or FDDI).

You should use PIM sparse mode with this feature. Therefore, when each Join message is received from NBMA neighbors, PIM stores each neighbor IP address and interface in the outgoing interface list for the group. When a packet is destined for the group, the software replicates the packet and unicasts (data-link unicasts) it to each neighbor that has joined the group.

Consider the following two factors before enabling PIM NBMA mode:

• If the number of neighbors grows, the outgoing interface list gets large, which costs memory and replication time.

• If the network (Frame Relay, SMDS, or ATM) supports multicast natively, you should use it so that replication is performed at optimal points in the network.

IP Multicast over ATM Point-to-Multipoint VCs is a feature that dynamically creates ATM point-to-multipoint switched virtual circuits (SVCs) to handle IP multicast traffic more efficiently.

This feature can enhance router performance and link utilization because packets are not replicated and sent multiple times over the ATM interface.

Traditionally, over NBMA networks, Cisco routers would perform a pseudobroadcast to get broadcast or multicast packets to all neighbors on a multiaccess network. For example, assume in the figure that Routers A, B, C, D, and E were running the Open Shortest Path First (OSPF) protocol. Router A must deliver to Routers D and E. When Router A sends an OSPF Hello packet, the data link layer replicates the Hello packet and sends one to each neighbor (this procedure is known as pseudobroadcast), which results in four copies being sent over the link from Router A to the multiaccess WAN.

With the advent of IP multicast, where high-rate multicast traffic can occur, the pseudobroadcast approach does not scale. Furthermore, in the preceding example, Routers B and C would get data traffic they do not need. To handle this problem, PIM can be configured in NBMA mode using the ip pim nbma-mode command. PIM in NBMA mode works only for sparse mode groups. Configuring PIM in NBMA mode would allow only Routers D and E to get the traffic without distributing to Routers B and C. However, two copies are still delivered over the link from Router A to the multiaccess WAN.

If the underlying network supported multicast capability, the routers could handle this situation more efficiently. If the multiaccess WAN were an ATM network, IP multicast could use multipoint VCs.

To configure IP multicast using multipoint VCs, Routers A, B, C, D, and E in the figure must run PIM sparse mode. If the Receiver directly connected to Router D joins a group and Router A is the PIM RP, the following sequence of events occurs:

1. Router D sends a PIM Join message to Router A.

2. When Router A receives the PIM join, it sets up a multipoint VC for the multicast group.

3. Later, when the Receiver directly connected to Router E joins the same group, Router E sends a PIM Join message to Router A.

4. Router A will see there is a multipoint VC already associated with the group, and will add Router E to the existing multipoint VC.

5. When the Source sends a data packet, Router A can send a single packet over its link that gets to both Router D and Router E. The replication occurs in the ATM switches at the topological diverging point from Router A to Router D and Router E.

If a host sends an IGMP report over an ATM interface to a router, the router adds the host to the multipoint VC for the group.

This feature can also be used over ATM subinterfaces.

An idling policy uses the ip pim vc-count command to limit the number of VCs created by PIM. When the router stays at or below the number configured, no idling policy is in effect. When the next VC to be opened will exceed the value, an idling policy is exercised. An idled VC does not mean that the multicast traffic is not forwarded; the traffic is switched to VC 0. VC 0 is the broadcast VC that is open to all neighbors listed in the map list. The name VC 0 is unique to PIM and the mroute table.