Protocol-Independent Multicast (PIM) is a family of multicast routing protocols for Internet Protocol (IP) networks that provide one-to-many and many-to-many distribution of data over a LAN, WAN or the Internet. It is termed protocol-independent because PIM does not include its own topology discovery mechanism, but instead uses routing information supplied by other routing protocols. PIM is not dependent on a specific unicast routing protocol; it can make use of any unicast routing protocol in use on the network. PIM does not build its own routing tables. PIM uses the unicast routing table for reverse-path forwarding.[1]: 56–57
Example of a multicast network architecture
There are four variants of PIM:
PIM Sparse Mode (PIM-SM) explicitly builds unidirectional shared trees rooted at a rendezvous point (RP) per group, and optionally creates shortest-path trees per source. PIM-SM generally scales fairly well for wide-area usage.[2]
PIM Dense Mode (PIM-DM) uses dense multicast routing. It implicitly builds shortest-path trees by flooding multicast traffic domain wide, and then pruning back branches of the tree where no receivers are present. PIM-DM is straightforward to implement but generally has poor scaling properties. The first multicast routing protocol, DVMRP used dense-mode multicast routing.[3] See RFC 3973.
Bidirectional PIM (Bidir-PIM) explicitly builds shared bi-directional trees. It never builds a shortest path tree, so may have longer end-to-end delays than PIM-SM, but scales well because it needs no source-specific state.[1]: 70–73 See RFC 5015.
PIM Source-Specific Multicast (PIM-SSM) builds trees that are rooted in just one source, offering a more secure and scalable model for a limited number of applications (mostly broadcasting of content). In SSM, an IP datagram is transmitted by a source S to an SSM destination address G, and receivers can receive this datagram by subscribing to channel (S,G). See informational RFC 3569.
PIM-SM is commonly used in IPTV systems for routing multicast streams between VLANs, Subnets or local area networks.[4]
There are two PIM versions. The versions are not directly compatible though may coexist on the same network. Network equipment may implement both versions. PIMv2 has the following improvements over PIMv1: A single RP is used per group. RP discovery is accomplished by a Bootstrap Router (BSR). Groups are either sparse or dense mode; Interfaces can be either. General improvements to protocol flexibility and efficiency.[1]: 59
Sparse mode
Protocol Independent Multicast - Sparse-Mode (PIM-SM) is a protocol for efficiently routingInternet Protocol (IP) packets to multicast groups that may span wide-area and inter-domain internets. The protocol is named protocol-independent because it is not dependent on any particular unicast routing protocol for topology discovery, and sparse-mode because it is suitable for groups where a very low percentage of the nodes (and their routers) will subscribe to the multicast session. Unlike earlier dense-mode multicast routing protocols such as DVMRP and dense multicast routing which flooded packets across the network and then pruned off branches where there were no receivers, PIM-SM explicitly constructs a tree from each sender to the receivers in the multicast group.[5]
Multicast clients
A router receives explicit Join/Prune messages from those neighboring routers that have downstream group members.
The router then forwards data packets addressed to a multicast group G to only those interfaces on which explicit joins have been received.
A Designated Router (DR) sends periodic Join/Prune messages toward a group-specific Rendezvous Point (RP) for each group for which it has active members.
Note that one router will be automatically or statically designated as the rendezvous point (RP), and all routers must explicitly join through the RP.
Each router along the path toward the RP builds a wild card (any-source) state for the group and sends Join/Prune messages on toward the RP.
The term route entry is used to refer to the state maintained in a router to represent the distribution tree.
A route entry may include such fields as:
source address
the group address
the incoming interface from which packets are accepted
the list of outgoing interfaces to which packets are sent
timers, flag bits, etc.
The wild card route entry's incoming interface points toward the RP
The outgoing interfaces point to the neighboring downstream routers that have sent Join/Prune messages toward the RP as well as the directly connected hosts which have requested membership to group G.
This state creates a shared, RP-centered, distribution tree that reaches all group members.
Multicast sources
When a data source first sends to a group, its Designated Router (DR) unicasts Register messages to the Rendezvous Point (RP) with the source's data packets encapsulated within.
If the data rate is high, the RP can send source-specific Join/Prune messages back towards the source and the source's data packets will follow the resulting forwarding state and travel un-encapsulated to the RP.
Whether they arrive encapsulated or natively, the RP forwards the source's de-capsulated data packets down the RP-centered distribution tree toward group members.
If the data rate warrants it, routers with local receivers can join a source-specific, shortest path, distribution tree, and prune this source's packets off the shared RP-centered tree.
For low data rate sources, neither the RP, nor last-hop routers need join a source-specific shortest path tree and data packets can be delivered via the shared RP-tree.
Once the other routers which need to receive those group packets have subscribed, the RP will unsubscribe to that multicast group, unless it also needs to forward packets to another router or node. Additionally, the routers will use reverse-path forwarding to ensure that there are no loops for packet forwarding among routers that wish to receive multicast packets.
Dense mode
Dense mode multicast is one mode that multicast can use to construct a tree for sending packets to the multicast subscribers. It is an alternative to sparse mode.
The basic assumption behind dense mode is that the multicast packet stream has receivers at most locations. Sparse mode assumes relatively fewer receivers. Dense mode is ideal for groups where many of the nodes will subscribe to receive the multicast packets, so that most of the routers must receive and forward these packets (groups of a high density).
This difference shows up in the initial behavior and mechanisms of the two protocols. Dense Mode uses a fairly simple approach to handle IP multicast routing. The source initially broadcasts to every router directly connected to it. These neighboring routers further forward the data to their neighbors. When a router does not wish to receive this group's data (if no other neighboring PIM routers are present and no host is interested in the group), it sends a Prune message to indicate its lack of interest. Upon receiving a Prune message, the router will modify its state so that it will not forward those packets out that interface. If every interface on a router is pruned, the router will also be pruned.[5]
In older Cisco IOS releases, PIM-DM would re-flood all the multicast traffic every 3 minutes. This is fine for low volume multicast, but not higher bandwidth multicast packet streams. More recent Cisco IOS versions support a new feature called PIM Dense Mode State Refresh, since 12.1(5)T. This feature uses a PIM state refresh messages to refresh the Prune state on outgoing interfaces. Another benefit is that topology changes are recognized more quickly. By default, the PIM state refresh messages are sent every 60 seconds.
Additionally, the routers will use reverse-path forwarding to ensure that there are no loops for packet forwarding among routers that wish to receive multicast packets. When a data packet is received on a non-RPF interface, a mechanism is required to prevent loops. If the non-RPF interface is a LAN, an Assert message is sent. Non-Forwarder routers then send a Prune on their RPF interface if they don't need the multicast stream. Only one such Prune is sent, at the time of the transition to having no interfaces in the Outgoing Interface List (OILIST). The LAN Prune receiver delays acting on it for 3 seconds, so that if another LAN router still needs the multicast stream, it can send a PIM Join message to counteract (cancel) the Prune. ("That router doesn't need it, but I still do!")
Suppose a router has Pruned, and some time later a receiver requests the multicast stream with an IGMP message. The router then sends a Graft message. In effect, "hey, I need that multicast stream over here now".
qpimd – PIM Daemon for Quagga - Protocol Independent Multicast, previously a separate independently released module for, but now an official module of and supplied by, the Quagga Routing Suite.
February 14, 2023
protocol, independent, multicast, protocol, independent, multicast, family, multicast, routing, protocols, internet, protocol, networks, that, provide, many, many, many, distribution, data, over, internet, termed, protocol, independent, because, does, include,. Protocol Independent Multicast PIM is a family of multicast routing protocols for Internet Protocol IP networks that provide one to many and many to many distribution of data over a LAN WAN or the Internet It is termed protocol independent because PIM does not include its own topology discovery mechanism but instead uses routing information supplied by other routing protocols PIM is not dependent on a specific unicast routing protocol it can make use of any unicast routing protocol in use on the network PIM does not build its own routing tables PIM uses the unicast routing table for reverse path forwarding 1 56 57 Example of a multicast network architecture There are four variants of PIM PIM Sparse Mode PIM SM explicitly builds unidirectional shared trees rooted at a rendezvous point RP per group and optionally creates shortest path trees per source PIM SM generally scales fairly well for wide area usage 2 PIM Dense Mode PIM DM uses dense multicast routing It implicitly builds shortest path trees by flooding multicast traffic domain wide and then pruning back branches of the tree where no receivers are present PIM DM is straightforward to implement but generally has poor scaling properties The first multicast routing protocol DVMRP used dense mode multicast routing 3 See RFC 3973 Bidirectional PIM Bidir PIM explicitly builds shared bi directional trees It never builds a shortest path tree so may have longer end to end delays than PIM SM but scales well because it needs no source specific state 1 70 73 See RFC 5015 PIM Source Specific Multicast PIM SSM builds trees that are rooted in just one source offering a more secure and scalable model for a limited number of applications mostly broadcasting of content In SSM an IP datagram is transmitted by a source S to an SSM destination address G and receivers can receive this datagram by subscribing to channel S G See informational RFC 3569 PIM SM is commonly used in IPTV systems for routing multicast streams between VLANs Subnets or local area networks 4 Contents 1 Versions 2 Sparse mode 2 1 Multicast clients 2 2 Multicast sources 3 Dense mode 4 See also 5 References 6 External linksVersions EditThere are two PIM versions The versions are not directly compatible though may coexist on the same network Network equipment may implement both versions PIMv2 has the following improvements over PIMv1 A single RP is used per group RP discovery is accomplished by a Bootstrap Router BSR Groups are either sparse or dense mode Interfaces can be either General improvements to protocol flexibility and efficiency 1 59 Sparse mode EditProtocol Independent Multicast Sparse Mode PIM SM is a protocol for efficiently routing Internet Protocol IP packets to multicast groups that may span wide area and inter domain internets The protocol is named protocol independent because it is not dependent on any particular unicast routing protocol for topology discovery and sparse mode because it is suitable for groups where a very low percentage of the nodes and their routers will subscribe to the multicast session Unlike earlier dense mode multicast routing protocols such as DVMRP and dense multicast routing which flooded packets across the network and then pruned off branches where there were no receivers PIM SM explicitly constructs a tree from each sender to the receivers in the multicast group 5 Multicast clients Edit A router receives explicit Join Prune messages from those neighboring routers that have downstream group members In order to join a multicast group G a host conveys its membership information through the Internet Group Management Protocol IGMP The router then forwards data packets addressed to a multicast group G to only those interfaces on which explicit joins have been received A Designated Router DR sends periodic Join Prune messages toward a group specific Rendezvous Point RP for each group for which it has active members Note that one router will be automatically or statically designated as the rendezvous point RP and all routers must explicitly join through the RP Each router along the path toward the RP builds a wild card any source state for the group and sends Join Prune messages on toward the RP The term route entry is used to refer to the state maintained in a router to represent the distribution tree A route entry may include such fields as source address the group address the incoming interface from which packets are accepted the list of outgoing interfaces to which packets are sent timers flag bits etc The wild card route entry s incoming interface points toward the RP The outgoing interfaces point to the neighboring downstream routers that have sent Join Prune messages toward the RP as well as the directly connected hosts which have requested membership to group G This state creates a shared RP centered distribution tree that reaches all group members Multicast sources Edit When a data source first sends to a group its Designated Router DR unicasts Register messages to the Rendezvous Point RP with the source s data packets encapsulated within If the data rate is high the RP can send source specific Join Prune messages back towards the source and the source s data packets will follow the resulting forwarding state and travel un encapsulated to the RP Whether they arrive encapsulated or natively the RP forwards the source s de capsulated data packets down the RP centered distribution tree toward group members If the data rate warrants it routers with local receivers can join a source specific shortest path distribution tree and prune this source s packets off the shared RP centered tree For low data rate sources neither the RP nor last hop routers need join a source specific shortest path tree and data packets can be delivered via the shared RP tree Once the other routers which need to receive those group packets have subscribed the RP will unsubscribe to that multicast group unless it also needs to forward packets to another router or node Additionally the routers will use reverse path forwarding to ensure that there are no loops for packet forwarding among routers that wish to receive multicast packets Dense mode EditDense mode multicast is one mode that multicast can use to construct a tree for sending packets to the multicast subscribers It is an alternative to sparse mode The basic assumption behind dense mode is that the multicast packet stream has receivers at most locations Sparse mode assumes relatively fewer receivers Dense mode is ideal for groups where many of the nodes will subscribe to receive the multicast packets so that most of the routers must receive and forward these packets groups of a high density This difference shows up in the initial behavior and mechanisms of the two protocols Dense Mode uses a fairly simple approach to handle IP multicast routing The source initially broadcasts to every router directly connected to it These neighboring routers further forward the data to their neighbors When a router does not wish to receive this group s data if no other neighboring PIM routers are present and no host is interested in the group it sends a Prune message to indicate its lack of interest Upon receiving a Prune message the router will modify its state so that it will not forward those packets out that interface If every interface on a router is pruned the router will also be pruned 5 In older Cisco IOS releases PIM DM would re flood all the multicast traffic every 3 minutes This is fine for low volume multicast but not higher bandwidth multicast packet streams More recent Cisco IOS versions support a new feature called PIM Dense Mode State Refresh since 12 1 5 T This feature uses a PIM state refresh messages to refresh the Prune state on outgoing interfaces Another benefit is that topology changes are recognized more quickly By default the PIM state refresh messages are sent every 60 seconds Additionally the routers will use reverse path forwarding to ensure that there are no loops for packet forwarding among routers that wish to receive multicast packets When a data packet is received on a non RPF interface a mechanism is required to prevent loops If the non RPF interface is a LAN an Assert message is sent Non Forwarder routers then send a Prune on their RPF interface if they don t need the multicast stream Only one such Prune is sent at the time of the transition to having no interfaces in the Outgoing Interface List OILIST The LAN Prune receiver delays acting on it for 3 seconds so that if another LAN router still needs the multicast stream it can send a PIM Join message to counteract cancel the Prune That router doesn t need it but I still do Suppose a router has Pruned and some time later a receiver requests the multicast stream with an IGMP message The router then sends a Graft message In effect hey I need that multicast stream over here now See also EditMulticast address Multicast Source Discovery ProtocolReferences Edit a b c IP Multicast Routing Configuration Guide Cisco retrieved 2017 05 27 PIM SM Multicast Routing Protocol Microsoft Retrieved 2014 03 26 Frequently Asked Questions FAQ File for Multicasting Multicast Tech Archived from the original on 2011 06 14 Supplement on guidelines on deployment of IP multicast for IPTV content delivery ITU T Retrieved 2014 03 23 a b Configuring IP Multicast Routing Cisco Systems retrieved 2013 12 06External links EditGorry Fairhurst 2006 PIM Routing PDF Archived from the original PDF on 2011 12 28 Retrieved 2011 12 06 Protocol Independent Multicast Sparse Mode PIM SM Protocol Specification Revised An Overview of Source Specific Multicast SSM Netcraftmen Explanation of PIM Sparse Mode PIM SM Multicast Routing Protocol pimd is a lightweight stand alone PIM SM v2 multicast routing daemon Protocol Independent Multicast Sparse Mode PIM SM Protocol Specification rfc2362 qpimd PIM Daemon for Quagga Protocol Independent Multicast previously a separate independently released module for but now an official module of and supplied by the Quagga Routing Suite Retrieved from https en wikipedia org w index php title Protocol Independent Multicast amp oldid 1119302299, wikipedia, wiki, book, books, library,
