Add Book to My BookshelfPurchase This Book Online

Chapter 7 - Protocol Independent Multicast-Sparse Mode

Cisco Multicast Routing & Switching
William R. Parkhurst
  Copyright © 1999 The McGraw-Hill Companies

PIM-SM — Protocol Operation  and Neighbor Discovery
PIM-SM version 1 packets are encapsulated in IGMP packets, as shown in Figure 7-3. PIM-SM packets have a common header that contains a code identifying the PIM-SM message type and the PIM mode: dense, sparse, or sparse-dense (see Figure 7-4). The message types are listed in Table 7-1 and neighbor discovery or router query messages are identified as type 0 (see Figure 7-5); the modes for PIM query messages are displayed in Table 7-2. Router query messages are used to discover neighbors that are attached to a common network. Discover may be a misleading term, however, because there is not an explicit neighbor list section comparable to a DVMRP neighbor discovery message.
Figure 7-3: Encapsulation of a PIM-SM version 1 packet in an IGMP datagram
Figure 7-4: PIM-SM version 1 packet header
Table 7-1: PIM-SM Version 1 Message Codes
Code
Message Type
0
Router Query
1
Register
2
Register-Stop
3
Join/Prune
4
RP Reachability
5
Assert
Figure 7-5: PIM-SM version 1 Query Message packet format
Table 7-2: PIM-SM version 1 Query Message modes
Code
Mode
0
Dense Mode
1
Sparse
2
Sparse-Dense
A better name for a router query message could be a neighbor inform message or a PIM Hello message. When a neighbor receives a query message, the IP address of the neighbor is recorded, but there is no explicit mechanism to acknowledge that the query was received. Instead, the receiving router simply transmits its own query message that has the effect of informing other PIM-SM routers on the network of its existence.
When a query message is received from a neighbor, will the interface be added to the outgoing interface list as it was in PIM-DM? The answer is no. PIM-SM uses an explicit join model; having a PIM-SM neighbor on an interface is not sufficient for adding the interface to the output interface list. A downstream receiver must join a group before traffic is forwarded on the interface. For a multi-access network, such as an ethernet, the query message is sent to the all-routers multicast address, 224.0.0.2, and serves as the Designated Router (DR) election mechanism. For sparse mode PIM, the designated router only has a function if IGMP version 1 is being used. In this case, the DR becomes the IGMP querier for the network (refer to Chapter 3, “Internet Group Management Protocol”). The elected DR is the PIM-SM enabled router with the highest IP address. The query process and DR election is shown in Figure 7-6. For this scenario, router C would be elected DR because it has the highest IP address on the multi-access network.
Figure 7-6: PIM-SM router query and DR election
The holdtime parameter in the router query message indicates how much time will elapse before this neighbor is declared dead. Subsequent router queries from a neighbor will reset this time, so the query interval must be less than the holdtime interval. The router queries act as a keep-alive mechanism to inform neighboring routers that this router is still alive and well. If PIM-SM is disabled on the interface or the router becomes disabled, then the holdtime for this router will expire on the neighboring routers. If the holdtime expires for a neighbor that was elected DR for the multi-access network, then a new DR will need to be elected.
PIM-SM Packet Forwarding
When a PIM-SM router receives the initial multicast packet from a source, the packet is flooded onto all interfaces in the output interface list (oilist). Recall that the oilist is populated with those interfaces that lead to downstream receivers which have indicated their desire to receive the traffic using IGMP. In PIM-DM, there is only one RPF interface for a particular source. With PIM-SM, there can be two RPF possibilities for a particular source, depending on whether the traffic is flowing down the shared tree or down the source tree (see Figure 7-7).
Figure 7-7: PIM-SM RPF check depends on the tree used.
Packet forwarding is similar to PIM-DM. If the group is in the oilist and it is not in the prune state, then the packet will be forwarded. One major difference between PIM-DM forwarding and PIM-SM forwarding is that in PIM-DM an interface is added to the oilist if a PIM-DM neighbor has been discovered on the interface or if a join has been received or forwarded from a neighbor. In PIM-SM, the interface will only be put in the list if the downstream neighbor has sent a join to this router, if there is a directly attached receiver for the group and a join has been received, or if the interface has been manually configured to join the group.
PIM-SM Joining  A leaf router will send a (*,G) Join message toward the RP if the leaf router has received a Join from a directly attached receiver or from a downstream neighbor. The router will forward the join to the RP along the unicast route, and each router along the path to the RP will process the Join. If a router does not have (*,G) state, then the state will be created and the Join will be sent toward the RP. If the router does have the state, then the Join message has reached the shared tree and the router does not have to do anything.
PIM-SM Registering  When a PIM-SM-enabled router initially receives a multicast packet from a sender, the router may or may not have the state for this source and group. A sender does not have to join the group it is sending to use IGMP. The router only needs to register with the RP using a PIM-SM register packet (see Figure 7-8).
Figure 7-8: PIM Sparse-Mode Register Packet Format
The Register packet is then sent as a unicast packet to the RP. The multicast packets that are received by the router directly attached to the source are encapsulated in Register messages, one per message. When the RP receives the Register message, the multicast packet will be extracted and sent down the shared tree toward the receivers. The RP will also send a (S,G) Join back toward the source in order to build the shortest path tree back to the source.
Once the path is established from the source to the RP, the source leaf router will begin to send multicast packets toward the RP as normal IP multicast packets. The source will also send the multicast packets encapsulated in Register messages, so the RP will receive them twice. When the RP detects that multicast packets from the source are being received as normal IP multicast packets, the RP sends a Register-Stop packet to the router directly attached to the source (see Figure 7-9).
Figure 7-9: PIM-Sparse Mode Register-Stop Packets
Upon reception of the Register-Stop message, the first-hop router will quit encapsulating the multicast traffic in Register messages and only send them to the RP as normal IP multicast packets. Figure 7-10 illustrates the registering process.
Figure 7-10: The PIM-SM RP Registration Process
PIM-SM Interface Pruning
When the last receiver for a group on an interface sends a version 2 IGMP Leave message or simply times out in IGMP version 1, then the router IGMP state for the group is deleted. Additionally, the interface is removed from the (*,G) and (S,G) entries on the oilist for the group G.
If the (*,G) state has been removed from every interface in the oilist, then a Prune message is sent up the shared tree towards the RP. If upstream routers do not have the state for the group, except on the interface on which the prune is received, then the Prune message is forwarded towards the RP. If the Prune message arrives at a router on the shared tree that still has receivers for the group on a different interface, the Prune message stops and is not forwarded toward the RP. The same procedure occurs if the router is receiving traffic on the source-based tree, instead of the shared tree. The format of the Prune/Join message is contained in Figure 7-11.
Figure 7-11: PIM Join/Prune packet format
The Upstream Neighbor Address is the address to which the Join/Prune packet is being sent. Its holdtime value indicates the lifetime of the Join/Prune. When a Prune is received, traffic from the source/group indicated in the Prune message is no longer forwarded onto the interface, while Join messages can be used to add a pruned interface to the oilist.
No Graft messages exist in PIM-SM because it is an explicit join model; Grafts instead are used in PIM-DM to add an interface back to the oilist if the interface is in the Prune state (in PIM-DM, Prune states expire and traffic is reflooded). Grafts can add an interface back in the oilist before the Prune state expires.
In PIM-SM, when an interface is pruned, the only way to add it back to the oilist is to use a Join message. The Mask Length (mask len) and Address Length (adr len) fields indicate the length in bytes of the mask and address for the group(s) to be pruned from the source-based delivery tree. Either the Prune list or the Join list may be empty, but a Join/Prune packet should never be sent when both the Join and Prune lists are empty. The format for the Group list is shown in Figure 7-12. The number of groups in the Group list is determined by the Number of Groups parameter in Figure 7-11.
Figure 7-12: Group list format
Each group is identified by the address and mask of the group to be pruned or joined. Following the Address and Mask Pair is the number of Join and Prune sources for the group. Join sources are listed first, followed by the Prune sources, and they are represented by the encoded format of Figure 7-13.
Figure 7-13: Encoded Source Address format
The S bit in the encoded source address format indicates whether or not this is a Sparse Mode group and should be set to 1 for Sparse Mode groups. The W bit is the wildcard bit and indicates whether the entry applies to a specific source/group (S,G), where W equals 0, or if the entry applies to all sources of the group (*,G), where W equals 1. The R bit applies to PIM-SM. Recall that in PIM-SM there can be either a source-based tree or a shared tree. The R bit indicates whether the packet is being sent toward the source (R = 0) or toward the RP (R = 1). The Len filed is the length of the source mask in bits and the source address is the IP address of the source to be joined or pruned.
Figure 7-14: Assert messages are used to prevent multiple copies of multicast traffic on a multi-access network.
PIM-SM Assert Message
To avoid duplicate multicast packets from traversing multi-access networks, PIM-SM uses the Assert message to determine a designated forwarding router for a multi-access network. Figure 7-14 demonstrates the situation that would warrant the Assert mechanism. The steps taken are as follows:
  1. Router A receives multicast traffic.
  2. Routers B and C are PIM-SM neighbors, so the multicast traffic is forwarded to routers B and C.
  3. Router D is a PIM-SM neighbor, so routers B and C forward the traffic onto the ethernet LAN. Assume router B transmits first. Router C receives the multicast packet on an interface that has this group in the oilist. This alerts router C to the fact that a PIM-SM neighbor on the ethernet LAN has forwarded traffic for the group.
  4. Router C forwards the multicast packet to routers B and D. B notices that the packet has arrived on an output interface for the group. Router D really doesn’t care because this router is not forwarding traffic for the group onto the ethernet LAN. Router D has received the same multicast packet twice, a situation that needs to be eliminated.
If a router receives a multicast packet for which it has a state, either (S,G) or (*,G) on an outgoing interface, then the router knows that there is another router forwarding packets onto the network. For example, the serial interfaces for both routers B and C are the RPF interfaces back to the multicast source. When router A receives a packet from the source, the packet is forwarded to both routers B and C. With no other mechanism in place, both routers B and C will forward the traffic to router D, creating duplicate packets on the network. Assert messages are used to avoid this situation.
An Assert message also contains the group address and mask for the multicast source and the router’s metric back to the source (see Figure 7-15). If both routers have an equal metric back to the source, then the router with the highest IP address becomes the forwarder for the network. The router that is not the forwarder prunes the interface.
Figure 7-15: PIM Assert packet format
Back in Figure 7-14, even though router D does not send Assert messages, it must listen to the Assert messages and determine which router is the designated router for the LAN. This information is necessary so that router D knows where to send Prune and Join messages for the group.
The Assert process is straightforward if both routers are running the same IP routing protocol. Recall that PIM-SM uses whatever protocol has been configured on the router to determine the RPF interface and the metric for the RPF interface. For the configuration in Figure 7-16, both routers on the multi-access network are running OSPF and the metrics back to the source are comparable. The OSPF metric is calculated by dividing 100,000,000 by the bandwidth of the link. The metric for the T1 link is approximately 67 and for the 28.8K link the metric is 3472. By comparing the metrics of the two links back to the source, we can easily choose the T1 link because it has a smaller metric than the 28.8K link. If different routing protocols are being utilized, then the metrics cannot be compared.
Figure 7-16: Routers B and C have comparable metrics to the source, so they can be used in an Assert message to elect the designated forwarder.
In Figure 7-17, router B is running OSPF and router C is running RIP. Comparing the metric back to the source for the two routers is like comparing apples and oranges. OSPF uses the speed of the interface to determine the metric and RIP uses a simple hop count. In this case, the metric preference value in the assert packet is used to determine which router will forward traffic and which router will prune the interface. Metric preference is analogous to an administrative distance for a unicast routing protocol. For example, the default administrative distance for RIP is 120 and for OSPF it is 110. Using the defaults always causes an OSPF route to be preferred over a RIP route.
Figure 7-17: Routers B and C have metrics that cannot be compared. The Assert mechanism would use the metric preference to determine the designated forwarder.
Metric preferences can also be configured for each unicast-routing protocol. When PIM-SM receives an Assert message for a group, the metric preference is compared to its own metric preference. If they are equal, then the metrics can be compared to determine which router will forward traffic. If the metric preference values are different, then the router with the lowest metric preference is selected as the forwarder on the network. If we assign a lower metric value for OSPF than for RIP, then the routers on the multi-access network in Figure 7-17 will select the OSPF router to forward traffic, and the RIP router will prune its interface for the group.
PIM-SM Version 2
PIM-SM version 2 is specified in RFC 2362, June 1998. In this section, we will examine the differences between PIM-SM versions 1 and 2. The first major change is that version 2 messages are no longer encapsulated in IGMP messages but are encapsulated in IP packets with protocol number 103 (see Figure 7-18). PIM-SM version 2 messages are sent to the multicast group 224.0.0.13, ALL-PIM-ROUTERS.
Figure 7-18: Encapsulation of a PIM-SM version 2 packet in an IP datagram
The PIM-SM version 2 packet header has been modified from the version 1 packet header (see Figure 7-19). The types of messages identified in the packet header, along with the version 1 types, are listed in Table 7-3. As you can see, there have been a few modifications from Table 7-1.
Figure 7-19: PIM-SM version 2 packet header format
Table 7-3: PIM versions 1 and 2 message types
Type
Description Version 2
Description Version 1
0
Hello
Router query
1
Register (Sparse mode)
Same
2
Register-Stop (Sparse mode)
Same
3
Join/Prune
Same
4
Bootstrap (Sparse mode)
RP Reachability (Sparse mode)
5
Assert
Same
6
Graft (Dense mode)
Same
7
Graft-Ack (Dense mode)
Same
8
Candidate RP advertisement
Type not used
The router query message that was used as the Neighbor Discovery mechanism in version 1 has been replaced by the Hello message, shown in Figure 7-20.
Figure 7-20: PIM-SM Version 2 Hello message format
The Option fields for the Hello message are listed in Table 7-4 and the values of the holdtime in Table 7-5.
Table 7-4: Hello message Option fields
Option Type
Option Length
Option Value
1
2
Hold time
2—16
Reserved
Reserved
Table 7-5: Hello message holdtime values
Value
Description
0xFFFF
No time out
0
Immediate time out
Any other value
Neighbor time out value
A timeout value of 0xFFFF means that the neighbor never expires. This value has the affect of preventing periodic Hello messages being sent and is useful on a tariff connection, such as ISDN. Periodic Hellos would keep the link active, even in the absence of user data traffic, but you may not be happy receiving an ISDN bill for nothing more than periodic Hello traffic. A holdtime of zero signifies that the neighbor should immediately time out.
The Prune/Join message format has been modified, as shown in Figure 7-21. The encoded unicast and multicast address formats are shown in Figures 7-22 and 7-23.
Figure 7-21: PIM version 2 Join/Prune packet format
Figure 7-22: PIM version 2 encoded unicast address format
Figure 7-23: Encoded Group address format
Encoding value is 0 and represents the native encoding for the address family (see Table 7-6). Further encoded address examples are shown in Figures 7-23 and 7-24. Figure 7-25 displays the PIM-SM version 2 Assert message format.
Table 7-6: Address Family Assignments
Number
Description
0
Reserved
1
IP Version 4
2
IP Version 6
3
NSAP
4
HDLC (*-bit multidrop)
5
BBN 1822
6
802
7
E.163
8
E.164 (SMDS, Frame Relay, ATM)
9
F.69 (Telex)
10
X.121 (X.25, Frame Relay)
11
IPX
12
AppleTalk
13
DECnet IV
14
Banyan Vines
15
E.164 with NSAP format subaddress
Figure 7-24: Encoded Source address
Figure 7-25: PIM-SM version 2 Assert message format
Figure 7-26: Static RP assignment. Only leaf routers need to be configured with the address of the RP.
The Rendezvous Point — Where Is It?
We assumed in all of the previous examples that the RP was configured and that the routers knew where it was. In this section, we will look at how this is accomplished. There are three methods that can be used to configure the RP. The first method is a static method and it requires configuring each leaf-designated router with the address of the RP for a group or range of groups. Leaf routers are those routers that have directly connected multicast sources or receivers (see Figure 7-26).
If the static RP method and one of the two dynamic RP methods are utilized simultaneously, the dynamic method takes precedence unless the static method is configured to take precedence, as we shall see when we look at the actual router configuration commands. Routers that may become designated routers in case the primary designated router fails need to be configured with the RP address. All the leaf routers in the PIM-SM domain are told where the RP is except for the RP itself! The RP is expected to deduce that it is the RP.
PIM version 1 uses a dynamic technique developed by Cisco called Auto-RP. Although one or more routers are statically configured as RPs, non-RP routers do not need to be configured with the address of the RPs. Configured RPs send RP announcements through all PIM-enabled interfaces with a configured TTL value that limits the scope of the announcement. These announcements are sent to the CISCO-RP-ANNOUNCE multicast group with address 224.0.1.39 and are received by an RP mapping agent, shown in Figure 7-27, which can also be the RP. This agent then sends the RP-to-group mappings to the group CISCO-RP-DISCOVERY (224.0.1.40). PIM-SM enabled routers listen to this group to determine the RP-to-group mappings (see Figure 7-28).
Figure 7-27: Rendezvous points send RP announcements that are received by the mapping agent.
Figure 7-28: Mapping agents send RP-to-group mappings that are received by PIM-SM-enabled routers.
The mapping agent does not seem to be necessary when there is only one RP in the PIM-SM domain, but if there are multiple RPs and the groups are announcing overlap, the mapping agent determines which router will be the RP for which groups. The mapping agent then distributes this information throughout the PIM-SM domain.
In PIM version 2 RP, information is disseminated using Bootstrap messages (see Figure 7-29).
Figure 7-29: PIM-SM Version 2 Bootstrap message format
Fragment Tag
A randomly generated number that is used to identify fragments. Fragment tags with the same value are from the same Bootstrap message.
HML
Hash Mask Length. The length of the mask to use in the Hash function.
BSR-priority
The Bootstrap router (BSR) priority of the included BSR.
Encoded Unicast BSR Address
The address of the Bootstrap router for the domain.
RP Count
The number of candidate RP addresses in the message for the corresponding group prefix.
Frag RP C
The number of candidate RP addresses in this fragment.
Encoded Unicast RP Address
The address of the candidate RPs for the corresponding group prefix.
RP Priority
The priority if the RP. Highest is 0.
The PIM-SM domain has a bootstrap router responsible for originating bootstrap messages. These messages are used to elect a BSR if needed (see Figure 7-30) and to distribute RP information that is sent to the multicast group ALL PIM ROUTERS (224.0.0.13). One or more routers are configured as candidate BSRs and the BSR candidate with the highest configured priority will be elected as the Bootstrap router (BSR). If all the priorities are equal, then the candidate BSR with the highest IP address will be elected, while another set of routers will be configured as candidate RPs. Usually the routers that are configured as candidate BSRs are also configured as candidate RPs, which will periodically send Candidate RP Advertisement messages to the elected BSR (see Figure 7-31). Candidate RP Advertisements are also sent to the BSR unicast address (see Figure 7-32).
Figure 7-30: Each candidate BSR sends Bootstrap messages that are used to elect the BSR.
Figure 7-31: Candidate RPs send RP announcements to the Bootstrap router.
Figure 7-32: PIM-SM version 2 Candidate RP advertisement
Prefix Count
Number of encoded group addresses in the message.
Priority
The priority of the RP for the encoded group address. Zero is highest.
Holdtime
The amount of time this advertisement is valid.
Encoded Unicast RP Address
The address of the candidate RP.
The Candidate RP advertisements contain the address of the Advertising Candidate RP as well as the groups that can be serviced by the candidate RP. The BSR periodically transmits this information throughout the domain and the PIM-SM routers receive and store it (see Figure 7-33). When a receiver joins a group using IGMP, the router maps the group address to one of the RPs and each candidate BSR sends Bootstrap messages that are used to elect the BSR.
Figure 7-33: The BSR collects RP announcements, determines the RP to group mappings, and disseminates the RP information throughout the network.
SPT Switchover
A threshold on a leaf router can be configured that, when exceeded, will cause the router to switch from the shared tree through the RP to the source tree. When PIM-SM is enabled, the default threshold is 0 kbps. This means that when the first packet is received from a multicast source, the router switches from the shared tree to the source tree. The threshold can be configured from 0 to infinity. A setting of infinity prevents the router from ever switching to the source tree.
The traffic for the group G from any source S is measured once each second. If the threshold is exceeded, then set a flag for (*,G) to remember that the threshold was exceeded. When the next packet for G arrives from any source, if the threshold exceeded flag is set, then clear the flag in (*,G), set the flag in (S,G), and switch to the source tree for that particular source. Again, every second the state of the flag is in (S,G) will be checked and if the traffic rate is less than the threshold, then switch back to the shared tree. The advantages of switching to the source tree is that traffic is being received on the shortest path tree. The shortest path tree will generally have a lower latency than the shared tree. The disadvantage is that (S,G) state will have to be maintained in the router. In other words, there is more detail that has to be maintained.

 


 
Books24x7.com, Inc © 2000 –  Feedback