PIM-Sparse Mode: Elements of Procedure
The PIM-SM protocol is based on the establishment of shared trees, where all multicast traffic for a group is routed through the tree that is based at a centralized rendezvous point. In PIM-SM route management, several types of messages are exchanged between participants.
By Mike Rodbell
In my
November column, we covered the general shared tree mechanism concepts employed in protocol independent multicast-sparse mode (PIM-SM). This month, we’ll examine the actual protocols used to manage multicast transmissions within the PIM-SM framework. As a quick review, PIM-SM’s main characteristics include:
•
Sparse mode region support.
Multi- cast participants are widely distributed in sparsely-populated multicast groups across the network. Many other multicast techniques rely
on some degree of flooding and pruning. Ad-hoc transmission of control messages isn’t a good idea when one considers that the data can be blasted all over the network, excessively consuming resources.
•
High-quality data distribution.
The multicast information should be sufficiently reliable to support the client applications.
•
Routing protocol independence.
Where- as many multicast routing techniques are joined at the hip with the underlying unicast routing protocols,
PIM-SM is designed to operate over networks where there can be more than one supporting routing protocol.
•
Interoperability with dense-mode protocols.
Dense-mode protocols support multicast over portions of the network where the group members are relatively close to one another. To allow each mechanism to support its designated configuration, PIM-SM can provide the glue that connects several widely distributed dense multicast areas.
•
Robustness.
PIM-SM must run over large networks,
and it must be able to survive some of the typical behaviors exhibited in widespread data networks. It’s not unusual for links to fail and/or congest, and routing topologies can change. PIM-SM can recover and adapt to these changes in the network.
Now let’s take a look at the protocol itself. The mechanisms employed by PIM-SM are functionally similar to the core-based tree (CBT) that I covered a few months back.
Basics of the protocol
The PIM-SM protocol is based on the
establishment of shared trees where all multicast traffic for a group is routed through the tree that is based at a centralized rendezvous point (RP). When new group memberships are created, the designated routers (DR) send join/prune messages towards the RP. As each intermediate PIM-capable router receives the message, it amends its multicast routing table and, if necessary, forwards the control message towards the RP.
With these trees established, multicast routing can be performed. When a host is ready to
send information to a group, it first directs all transmissions to the group’s RP. Once the messages have arrived at the RP, they are forwarded along all of the outbound interfaces through the tree, being delivered to all of the intermediate routers, and ultimately, to all group participants spread throughout the network.
Several types of messages are exchanged between the participants in the PIM-SM route management process. If you’re familiar with other data route management protocols, you
shouldn’t find any surprises here. Many route management issues handled by PIM-SM aren’t much different from those issues appearing in other routing problems. The general types of messages that are exchanged in PIM-SM include:
•
Hello messages.
These messages allow neighboring routers to discover each other; the hello messages provide a basic discovery and state-of-health service. The lack of a hello message (after a prescribed amount of time) is used to indicate that a particular
router is no longer available.
•
Join/prune messages.
These are the control messages exchanged between the various routers to manage the actual routing trees. A number of strategies exist for the exchange of these messages. More about that later.
•
Register and register-stop messages.
These messages manage the establishment (and disestablishment) of group routes. When a source first sends traffic to a group, the packets are contained in register messages. If appropriate, the
receiving RP will initiate a process that points the tree core towards the originating source. As the tree is constructed, the corresponding traffic can traverse an optimized path through the network.
•
Multicast data.
These data are the actual packets containing the user data. Based on the group membership (address), and the multicast routing tree, the data packets are forwarded through the tree. The path taken through the network complies with the outbound interface (OIF) of each PIM-SM capable
multicast router.
•
Assert messages.
Assert messages are used to select the DR for a LAN where multiple candidate routers exist.
•
Candidate-RP-advertisements.
These messages support the bootstrap process. Each candidate RP (C-RP) periodically sends this message to the area’s bootstrap router (BSR) to indicate their availability to act as an RP for multicast transmissions.
Along with these basic messages, the protocol specification identifies a number of other functions and
events that occur in the process of managing sparse multicast routes. These items include the hash function, which helps identify C-RPs for a specific group, and a series of timers which track the health state of the range of operations occurring between the several entities participating in the PIM-SM process.
Principles of operation
Now that we’ve covered some of the basic types of messages that can be sent in the PIM-SM protocol, we can review the general operations required to manage
the routes and to send information over the network. Given that the messages I’ve identified in the earlier part of this column cover an extensive range of types and formats, we’ll focus primarily on types of exchanges. For specifics on the actual message contents, refer to Request For Comment (RFC) 2362. (Internet RFCs can be found at www.rfc-editor.org/rfc.html.) RFC 2362 contains a more complete description of the protocol, which is still considered to be in the experimental stage.
Establishing the routing trees
The most fundamental service provided by PIM-SM is the establishment of the routing trees. Generally, the routing trees start with an RP-rooted orientation, in which all traffic for a particular group is first sent to the RP. The multicast traffic is then transferred on the branches of the tree until all leaves (end-points) have been reached.
When a designated router (DR) determines that it needs to support a new multicast group, the DR then creates a join/prune message
that it forwards towards the RP. As the intermediate multicast routers receive the join/prune message, they first check to see if the requested route is already being supported. If the group is supported by the router, the router merely joins the requesting route to its (already established) tree. If no route exists, the router forwards the request towards the RP and marks the route in its cache. If subsequent join/prune messages are received for the original group, they can then be “joined” to
the previously established route.
In some cases, a randomly selected RP doesn’t provide the most efficient path for multicast traffic distribution. Think about an application where there is a single transmitter for a given group. If the traffic has to find its way from the transmitter to a different RP, all of the traffic must traverse the additional network overhead to get from the source to the RP. If the sole traffic source becomes the RP, then the traffic can traverse a more efficient set of
routes, with the multicast packets spreading across a tree whose root is the source. This application is called the shortest path tree (SP-tree).
PIM-SM provides a set of mechanisms to enable switching from a shared tree (RP-based) to an SP-tree. The transitions from the RP-tree to the SP-tree are handled by first having the routers join a shared tree. Once the router has received packets from the source, it can then switch to the selected source’s SP-tree. This switch occurs when the receiving router
sends join/prune messages to the source (rather than to the RP), and when the SP-tree deletes the previous RP-based tree membership.
Tree maintenance
Once a router has become part of one or more multicast trees, it must perform a set of maintenance functions to keep its membership within the various trees. Put simply, each router will periodically send a set of join/prune messages to its tree peers to indicate its continued interest in supporting its multicast trees. There is no prescribed
mechanism for acknowledgement of these messages. They are primarily employed to ensure that the active routes persist across the complete set of routers.
Traffic routing with PIM-SM
With all of this discussion on tree establishment, we still need to talk a bit about how the multicast packets are routed through the network. This routing is actually the simpler portion of the PIM-SM algorithms. Once the routing trees have been established (either RP-based or SP-based), the packets are passed through
the network according to the routing lists maintained by the multicast-capable routers in the network. As multicast traffic is received by a subnet’s DR, the traffic is encapsulated into PIM-SM multicast data packets, which are forwarded as unicast packets between the PIM-SM routers on the particular group’s tree. When the multicast data packets reach the final routers on the network to be forwarded to the individual group members, the packets are broken back into their original form and
distributed using local multicast mechanisms. These mechanisms can take one of two general forms, either forwarding to a dense-mode multicast algorithm (such as DVMRP or MOSPF) or as standard IP-multicast packets.
This column is the last in the series on Internet multicast. As you may have gathered from reviewing the last several months of columns, some of the multicast protocols are mature, and some of the efforts are in various stages of research and experimentation. The MBONE efforts have gone a long way in
fueling this research. As the Internet evolves, backbone bandwidth increases, access becomes ubiquitous, and broadcast media moves to digital formats. Applications will continue to drive the technology, and acceptance of IP multicast standards will mature. If and when that maturity happens, tree-based solutions such as PIM-SM are likely to be among the set of technologies managing multicast transmissions.
Mike Rodbell is director of embedded software development for CIENA Communications Inc. He has
developed voice and data communications systems for a wide range of commercial and military systems. He holds a BSCS from Trinity College of Hartford, CT, and an MSEE from Loyola College of Baltimore, MD. He can be reached at mrodbell@ciena.com or www.ciena.com.
Puzzled by a network processing design issue?
