Developing IP Multicast Networks Developing IP Multicast Networks ● About the Author ● Introduction to IP Multicast ● Multicast Basics ● Internet Group Management Protocol ● Mutlimedia Multicast Applications ● Distance Vector Multicast Routing Protocol ● PIM Dense Mode ● PIM Sparse Mode ● Core-Based Trees ● Multicast Open Shortest Path First ● Using PIM Dense Mode ● Using PIM Sparse Mode ● PIM Rendezvous Points ● Connecting to DVMRP Networks ● Multicast over Campus Networks file:///V|/[%20CISCO%20PRESS%20]/Ciscopress-Developing.Ip.Multicast.Networks/index.htm (1 of 2)09/12/2003 01:11:38 Developing IP Multicast Networks ● Multicast over NBMA Networks ● Multicast Traffic Engineering ● Inter-Domain Multicast Routing ● Introduction ● Preface ● Appendix A-PIM Packet Formats Copyright 1989-2000 © Cisco Systems Inc file:///V|/[%20CISCO%20PRESS%20]/Ciscopress-Developing.Ip.Multicast.Networks/index.htm (2 of 2)09/12/2003 01:11:38 About the Author Table of Contents About the Author About the Technical Reviewers Acknowledgments About the Author Beau Williamson is a consulting engineer in the Office of the CTO at Cisco Systems His area of expertise is general IP networking, and he is currently focused on IP multicast He received a B.S degree in mathematics (with a specialty in computer science) from the University of Texas (Dallas) in 1984 and has been working in the computer and networking technology fields for more than 20 years He is frequently called upon by Cisco customers and internal Cisco engineers around the world to provide consulting services on the design, implementation, and debugging of IP multicast networks Beau is also the author and developer of Cisco's internal IP multicast training class and frequent presenter on topics related to IP multicast at Cisco Networkers and Cisco Certified Internetwork Expert (CCIE) conferences both at home and abroad He lives in the Dallas, Texas, area with his wife and son When not working on IP multicast, he enjoys a wide range of hobbies, including amateur radio, golf, woodworking, and flying his own plane About the Technical Reviewers Dino Farinacci has been designing and implementing networking protocols for 18 years He has extensive experience with distance-vector and link-state protocol implementations, as well as with multicast routing protocols, which have been his focus for the past years Dino currently works for Cisco Systems in the multimedia group He has been an active member of the IETF for more than 10 years, where he has been involved in the design of Open Shortest Path First (OSPF), Protocol Independent Multicast (PIM), and various IPng candidates He was a member of the IPng directorate for a short period of time, where he helped the IETF converge on a single IPng solution Currently, he is concentrating on multicast tag switching, inter-domain policy-based multicast routing, and reliable multicast protocols He is one of the principal engineers in the Internet to deploy Cisco multicast routers on the MBone and in many native production ISP infrastructures Kevin Almeroth is an assistant professor at the University of California in Santa Barbara His research file:///V|/[%20CISCO%20PRESS%20]/Ciscopress-Developing.Ip.Multicast.Networks/di10auth.htm (1 of 2)09/12/2003 01:11:38 About the Author interests include computer networks and protocols, multicast communication, large-scale multimedia systems, and performance evaluation In addition to his research activities, Dr Almeroth is an active participant in several Internet Engineering Task Force (IETF) working groups, has helped manage multicast for Networld+Interop as part of the Network Operations Center (NOC) team, is a senior technologist for the IP Multicast Initiative, and is the multicast working group chair for Internet2 Erick Mar is a senior systems engineer at Cisco Systems with CCIE certification in routing and switching (CCIE #3882) As a systems engineer for the last years for various networking manufacturers, he has provided design and implementation support for Fortune 500 companies Erick has an MBA from Santa Clara University and a B.S in business administration from San Francisco State University Bob Quinn is senior technologist for Stardust.com, where he writes white papers and tracks IETF developments for the IP Multicast Initiative and QoS Forum He is the principal author of the wellregarded Windows Sockets Network Programming (Addison-Wesley) and chairman of the WinSock Editorial Board that oversees new developments and issues in WinSock application programming interfaces (APIs) You can reach him at rcq@stardust.com Acknowledgments This book would not have been possible without the support of scores of people, all of whom I can't possibly enumerate but to whom I'm deeply indebted In particular, I wish to thank Dino Farinacci; Liming Wei; and their manager, Achutha Rao, from the IP multicast development group at Cisco Dino and Liming's support and patience through numerous questions and discussions on the topic of IP multicast went far beyond the call of duty I also wish to express my thanks to my development editor, Kathy Trace, who suffered through all my deadline slips and bizarre manuscript format requirements, in addition to generally being my confidant when I needed to bounce ideas off of someone Furthermore, I wish to thank my technical reviewers, Dino Farinacci, Manoj Leelanivas, Kevin Almeroth, Erick Mar, and Bob Quinn for their excellent input on the technical content of this book Finally, I owe a tremendous thanks to my wife and my son who provided support and patience as well as tolerating my occasional loud outbursts directed at the word processing software on my PC when it produced unexpected results Posted: Tue Mar 21 14:54:16 PST 2000 Copyright 1989 - 2000©Cisco Systems Inc file:///V|/[%20CISCO%20PRESS%20]/Ciscopress-Developing.Ip.Multicast.Networks/di10auth.htm (2 of 2)09/12/2003 01:11:38 Introduction to IP Multicast Table of Contents Introduction to IP Multicast A Brief History of IP Multicast The Pros of IP Multicast Bandwidth Server Load Network Loading The Cons of IP Multicast Unreliable Packet Delivery Packet Duplication Network Congestion Multicast Applications Multimedia Conferencing Data Distribution Real-Time Data Multicasts Gaming and Simulations MBone -The Internet's Multicast Backbone MBone Sessions History of the MBone Today's MBone Architecture Tomorrow's MBone Architecture Summary Introduction to IP Multicast At one end of the IP communication spectrum is IP unicast communication, where a source IP host sends packets to a specific destination IP host In this case, the destination address in the IP packet is the address of a single, unique host in the IP network These IP packets are forwarded across the network from the source host to the destination host by routers The routers at each point along the path between the source and destination use their unicast Routing Information Base (RIB) to make unicast forwarding decisions based on the IP destination address in the packet At the other end of the IP communication spectrum is an IP broadcast, where a source host sends packets to all IP hosts on a network segment The destination address of an IP broadcast packet has the host portion of the destination IP address set to all ones and the network portion set to the address of the file:///V|/[%20CISCO%20PRESS%20]/Ciscopress-Developing.Ip.Multicast.Networks/di10ch01.htm (1 of 20)09/12/2003 01:11:40 Introduction to IP Multicast subnet (see Figure 1-1) (In some cases the host portion is set to all zeros, but this form of IP broadcast address is generally no longer used.) Figure 1-1: IP Broadcast Addresses IP hosts (including routers) understand that packets, which contain an IP broadcast address as the destination address, are addressed to all IP hosts on the subnet Unless specifically configured otherwise, routers not forward IP broadcast packets and, therefore, IP broadcast communication is normally limited to the local subnet Figure 1-2 clearly illustrates this point Figure 1-2: IP Broadcast Being Blocked by a Router In this example, Host A sends out a broadcast to the local subnet 198.1.1.0/24 Because Hosts B and C are on the same subnet as Host A, they receive the broadcast Host D, however, is on a different subnet (198.1.2.0/24) and does not receive the broadcast because the router does not forward broadcasts If routers forwarded these broadcasts, route loops are likely to cause a catastrophic broadcast storm If your goal is to permit a host to send IP packets to other hosts not on the local subnet, then IP broadcasting is not sufficient to accomplish this goal IP multicasting falls between IP unicast and IP broadcast communication and enables a host to send IP file:///V|/[%20CISCO%20PRESS%20]/Ciscopress-Developing.Ip.Multicast.Networks/di10ch01.htm (2 of 20)09/12/2003 01:11:40 Introduction to IP Multicast packets to a group of hosts anywhere within the IP network To so, the destination address in an IP multicast packet is a special form of IP address called an IP multicast group address (The format of IP multicast group addresses and exactly how hosts become members of a multicast group are explained in Chapter 2, "Multicast Basics.") IP multicast routers must forward incoming IP multicast packets out all interfaces that lead to members of the IP multicast group The IP multicast group address is specified in the IP destination address field of the packet Exactly how the routers learn which interface to forward the packet to is part of the magic of IP multicast routing The explanation of how this magic works is one of the goals of this book By the time you finish reading this book, you should have a good understanding not only of how IP multicasting works in general but also of how to design efficient IP multicast networks using Cisco routers This chapter offers a brief history of IP multicasting, a discussion on the pros and cons of multicast, a description of various multicast applications, and an introduction to the multicast backbone A Brief History of IP Multicast At Stanford University in the early 1980s, a doctoral graduate student, Steve Deering, was working on a distributed operating system project for his advisor, David Cheriton This distributed operating system was called Vsystem and was composed of several computers tied together into a loosely coupled multiprocessing system via a single Ethernet segment The computers on this Ethernet segment worked together and communicated at the operating system level via special messages sent on the common Ethernet segment One of the operating system primitives permitted one computer to send a message to a group of the other computers on the local Ethernet segment using a MAC layer multicast As the project progressed, the need arose to add more computers to the multiprocessing system Unfortunately, the only available computers were on the other side of the campus with production routers between the two networks Consequently, the graduate students had to extend the operating system's inter-processor communications to work at Layer of the OSI reference model so that the computers on the other side of the campus could function as part of the loosely coupled multiprocessor system In addition, the MAC layer multicast messaging would also have to be extended to work at Layer The task of finding a way to extend the MAC layer multicast capability across the Layer routed network primarily fell to Steve Deering After studying the Open Shortest Path First (OSPF) Protocol and the Routing Information Protocol (RIP) IP routing protocols, Steve concluded that the link-state mechanisms of OSPF could certainly be extended to support multicasting He also concluded that the basic mechanisms of RIP could be used as the basis for a new distance vector-based multicast routing protocol This idea led to more research into the area of IP multicasting and ultimately resulted in Steve Deering's doctoral thesis, "Multicast Routing in a Datagram Network," published in December 1991 Dr Deering's thesis also described a Host Membership Protocol, which became the basis for today's file:///V|/[%20CISCO%20PRESS%20]/Ciscopress-Developing.Ip.Multicast.Networks/di10ch01.htm (3 of 20)09/12/2003 01:11:40 Introduction to IP Multicast Internet Group Membership Protocol (IGMP) that IP multicast hosts use to signal to the router on the network that they desire to join a multicast group In addition, Dr Deering's thesis described a distance vector-based IP multicast routing protocol that was the basis for the Distance Vector Multicast Routing Protocol (DVMRP), also developed by Dr Deering a few years later These two protocols provided the first successful extensions to the IP packet network model to allow multicasting to be extended to Layer of the OSI model Since that time, advances in IP multicasting technology have continued and additional protocols such as Protocol Independent Multicasting (PIM) and multiprotocol extensions to the Border Gateway Protocol (BGP) have been developed These protocols permit IP multicasting to scale beyond the initial limited implementations to large, enterprise-wide multicast networks and eventually on to a native, completely multicast-enabled Internet The Pros of IP Multicast As the Internet and, in many cases, company intranets have grown in terms of the number of connected users, a large number of users frequently want to access the same information at roughly the same time Using IP multicast techniques to distribute this information can often substantially reduce the overall bandwidth demands on the network A good example of this approach is the rapidly growing area of audio and video Web content Here's an example: The ACME Company is using a bank of audio servers to transmit popular radio talkshow content, such as the Rush Limbaugh and Howard Stern shows, in real time to connected subscribers over the Internet This is just one of many areas in which IP multicasting can provide significant advantages to the network providers as well as the content providers both on the Internet or within company intranets However, it's doubtful that employees who tune in to Howard Stern through their company's Internet connection are actually performing a mission-critical task Of course, if they happen to be in the entertainment business or work for the FCC, this might be considered an important job-related task In the next few sections, the ACME Company example is used to illustrate some of the pros of IP multicasting These include (but are not limited to) the following advantages: bandwidth, server load, and network loading Bandwidth Consider, as an example, the way that the ACME Company is transmitting real-time feeds of the Rush Limbaugh talk show via an audio compression technique that requires an 8-kbps data stream to deliver The dashed line on the graph in Figure 1-3 shows that as the number of connected unicast subscribers increases, the amount of network bandwidth also increases linearly On the other hand, if you are multicasting the same program (represented by the solid line), a single 8-kbps multicast data stream can deliver the program to the subscribers file:///V|/[%20CISCO%20PRESS%20]/Ciscopress-Developing.Ip.Multicast.Networks/di10ch01.htm (4 of 20)09/12/2003 01:11:40 Introduction to IP Multicast Figure 1-3: Unicast Versus Multicast Bandwidth for Audio Given that ACME's revenues are based on the number of subscribers (which would somehow relate to the active number of clients at any time), it is reasonable to expect that ACME's marketing department goals are to see the number of clients in the tens of thousands Meeting this goal is going to require engineering the network to provide bandwidths in the 100 Mbps range in order to support this single scenario Now, suppose that ACME has been very successful with this product and wants to extend its service offering to include highly compressed, low-rate, 120-kbps video streams to go along with the 8-kbps audio programs Figure 1-4 shows that if the unicast model continues to be used as the delivery method, the bandwidth requirements are driven even higher Figure 1-4: Unicast Versus Multicast Bandwidth for Video Assuming that, in the future, more and more Internet-connected subscribers have the ISDN, ADSL, or other medium-rate Internet connections necessary to watch ACME's program content and are tuned in, bandwidth demands can approach the multimegabit range If you further consider that some form of competition in this marketplace exists, ACME will not be the only supplier of this sort of program content Other companies will begin offering similar services via the Internet, which will place additional demands on the Internet's infrastructure file:///V|/[%20CISCO%20PRESS%20]/Ciscopress-Developing.Ip.Multicast.Networks/di10ch01.htm (5 of 20)09/12/2003 01:11:40 Introduction to IP Multicast At this writing, several movie services were beginning to investigate the possibilities of distributing movies via data networks Considering that a typical MPEG-2 video stream requires roughly 1.5 Mbps of bandwidth for a reasonably artifact-free video, IP multicasting is clearly an excellent choice for delivering this type of program content Although you may have to wait some time before you can watch Arnold Schwarzenegger in the latest Terminator III at home via your Internet connection, you are quite likely to receive MPEG-2 multicasts of important company events over your company's IP network Server Load Return to the example of the ACME Company's delivery of real-time audio to connected subscribers via the Internet If ACME continues to use a unicast delivery mechanism, it will need to continue to increase the power and number of its real-time audio servers to meet the increasing number of connected subscribers Figure 1-5 shows an example of the number of flows that a real-time audio server must source to deliver Rush Limbaugh's talk show to three clients Notice that in the unicast case (shown at the top of Figure 15), the server must source a separate flow for each client listening to the program Figure 1-5: Server Load As the number of connected clients increases, the load on the server is going to increase until, at some point, the server will be unable to source the flows at the 8-kbps data rate necessary to deliver unbroken file:///V|/[%20CISCO%20PRESS%20]/Ciscopress-Developing.Ip.Multicast.Networks/di10ch01.htm (6 of 20)09/12/2003 01:11:40 Appendix A-PIM Packet Formats \Q0xffff', the receiver of this message never times out the oif This may be used with ISDN lines, to avoid keeping the link up with periodical Join/Prune messages Furthermore, if the Holdtime is set to \Q0', the information is timed out immediately Number of Groups The number of multicast group sets contained in the message Encoded-Multicast group address For format description see Section 4.1 A wild card group in the (*,*,RP) join is represented by a 224.0.0.0 in the group address field and \Q4' in the mask length field A (*,*,RP) join also has the WC-bit and the RPT-bit set Number of Joined Sources Number of join source addresses listed for a given group Join Source Address-1 n This list contains the sources that the sending router will forward multicast datagrams for if received on the interface this message is sent on See format section 4.1 The fields explanation for the Encoded-Source-Address format follows: Reserved file:///V|/[%20CISCO%20PRESS%20]/Ciscopress-Developing.Ip.Multicast.Networks/di10xa.htm (14 of 28)09/12/2003 01:12:17 Appendix A-PIM Packet Formats Described above S The Sparse bit is a bit value, set to for PIM-SM It is used for PIM v.1 compatibility W The WC bit is a bit value If 1, the join or prune applies to the (*,G) or (*,*,RP) entry If 0, the join or prune applies to the (S,G) entry where S is Source Address Joins and prunes sent towards the RP must have this bit set R The RPT-bit is a bit value If 1, the information about (S,G) is sent towards the RP If 0, the information must be sent toward S, where S is the Source Address Mask Length, Source Address Described above Represented in the form of < WC-bit >< RPT-bit >< Source address>: A source address could be a host IPv4 native encoding address : < >< >< 32 >< 192.1.1.17 > A source address could be the RP's IP address : < >< >< 32 >< 131.108.13.111 > A source address could be a subnet address to prune from the RP-tree : < >< >< 28 >< 192.1.1.16 > file:///V|/[%20CISCO%20PRESS%20]/Ciscopress-Developing.Ip.Multicast.Networks/di10xa.htm (15 of 28)09/12/2003 01:12:17 Appendix A-PIM Packet Formats A source address could be a general aggregate : < >< >< 16 >< 192.1.0.0 > Number of Pruned Sources Number of prune source addresses listed for a group Prune Source Address-1 n This list contains the sources that the sending router does not want to forward multicast datagrams for when received on the interface this message is sent on If the Join/Prune message boundary exceeds the maximum packet size, then the join and prune lists for the same group must be included in the same packet Bootstrap Message Bootstrap messages are multicast to All-PIM-Routers group, out all interfaces having PIM neighbors (excluding the one over which the message was received) Bootstrap messages are sent with a Time To Live (TTL) value of Bootstrap messages originate at the bootstrap router (BSR) and are forwarded by intermediate routers Bootstrap messages are divided up into semantic fragments if the original message exceeds the maximum packet-size boundaries The semantics of a single fragment follows: 0123 01234567890123456789012345678901 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |PIM Ver| Type | Reserved | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ file:///V|/[%20CISCO%20PRESS%20]/Ciscopress-Developing.Ip.Multicast.Networks/di10xa.htm (16 of 28)09/12/2003 01:12:17 Appendix A-PIM Packet Formats | Fragment Tag | Hash Mask len | BSR-priority | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Encoded-Unicast-BSR-Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Encoded-Group Address-1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RP-Count-1 | Frag RP-Cnt-1 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Encoded-Unicast-RP-Address-1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RP1-Holdtime | RP1-Priority | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Encoded-Unicast-RP-Address-2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RP2-Holdtime | RP2-Priority | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |.| |.| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Encoded-Unicast-RP-Address-m | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RPm-Holdtime | RPm-Priority | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Encoded-Group Address-2 | file:///V|/[%20CISCO%20PRESS%20]/Ciscopress-Developing.Ip.Multicast.Networks/di10xa.htm (17 of 28)09/12/2003 01:12:17 Appendix A-PIM Packet Formats +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |.| |.| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Encoded-Group Address-n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RP-Count-n | Frag RP-Cnt-n | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Encoded-Unicast-RP-Address-1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RP1-Holdtime | RP1-Priority | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Encoded-Unicast-RP-Address-2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RP2-Holdtime | RP2-Priority | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |.| |.| |.| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Encoded-Unicast-RP-Address-m | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RPm-Holdtime | RPm-Priority | Reserved | file:///V|/[%20CISCO%20PRESS%20]/Ciscopress-Developing.Ip.Multicast.Networks/di10xa.htm (18 of 28)09/12/2003 01:12:17 Appendix A-PIM Packet Formats +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ PIM Version, Type, Reserved, Checksum Described above Fragment Tag A randomly generated number, acts to distinguish the fragments belonging to different Bootstrap messages; fragments belonging to same Bootstrap message carry the same \QFragment Tag' Hash Mask len The length (in bits) of the mask to use in the hash function For IPv4 we recommend a value of 30 For IPv6 we recommend a value of 126 BSR-priority Contains the BSR priority value of the included BSR This field is considered as a high order byte when comparing BSR addresses Encoded-Unicast-BSR-Address The address of the bootstrap router for the domain The format for this address is given in the Encoded-UnicastAddress in 4.1 .IP "Encoded-Group Address-1 n" The group prefix (address and mask) with which the Candidate RPs are associated Format previously described RP-Count-1 n The number of Candidate RP addresses included in the whole file:///V|/[%20CISCO%20PRESS%20]/Ciscopress-Developing.Ip.Multicast.Networks/di10xa.htm (19 of 28)09/12/2003 01:12:17 Appendix A-PIM Packet Formats Bootstrap message for the corresponding group prefix A router does not replace its old RP-Set for a given group prefix until/unless it receives \QRP-Count' addresses for that prefix; the addresses could be carried over several fragments If only part of the RP-Set for a given group prefix was received, the router discards it, without updating that specific group prefix's RP-Set Frag RP-Cnt-1 m The number of Candidate RP addresses included in this fragment of the Bootstrap message, for the corresponding group prefix The \QFrag RP-Cnt' field facilitates parsing of the RP-Set for a given group prefix, when carried over more than one fragment Encoded-Unicast-RP-address-1 m The address of the Candidate RPs, for the corresponding group prefix The format for this address is given in the Encoded-Unicast-Address in 4.1 .IP "RP1 m-Holdtime" The Holdtime for the corresponding RP This field is copied from the \QHoldtime' field of the associated RP stored at the BSR RP1 m-Priority The \QPriority' of the corresponding RP and Encoded-Group Address This field is copied from the \QPriority' field file:///V|/[%20CISCO%20PRESS%20]/Ciscopress-Developing.Ip.Multicast.Networks/di10xa.htm (20 of 28)09/12/2003 01:12:17 Appendix A-PIM Packet Formats stored at the BSR when receiving a Candidate-RPAdvertisement The highest priority is \Q0' (i.e the lower the value of the \QPriority' field, the higher) Note that the priority is per RP per Encoded-Group Address Assert Message The Assert message is sent when a multicast data packet is received on an outgoing interface corresponding to the (S,G) or (*,G) associated with the source This message is used in both dense mode and sparse mode PIM: 0123 01234567890123456789012345678901 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |PIM Ver| Type | Reserved | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Encoded-Group Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Encoded-Unicast-Source Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R| Metric Preference | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Metric | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ PIM Version, Type, Reserved, Checksum Described above Encoded-Group Address file:///V|/[%20CISCO%20PRESS%20]/Ciscopress-Developing.Ip.Multicast.Networks/di10xa.htm (21 of 28)09/12/2003 01:12:17 Appendix A-PIM Packet Formats The group address to which the data packet was addressed, and which triggered the Assert Format previously described Encoded-Unicast-Source Address Source address from multicast datagram that triggered the Assert packet to be sent The format for this address is given in the Encoded-Unicast-Address in 4.1 .IP "R" RPT-bit is a bit value If the multicast datagram that triggered the Assert packet is routed down the RP tree, then the RPT-bit is 1; if the multicast datagram is routed down the SPT, it is Metric Preference Preference value assigned to the unicast routing protocol that provided the route to Host address Metric The unicast routing table metric The metric is in units applicable to the unicast routing protocol used Graft Message (Dense Mode Only) Graft messages are sent by a downstream router to a neighboring upstream router to reinstate a previously pruned branch of a SPT (This is done for dense mode groups only.) The format is the same as a Join/Prune message except that the value in the Type field is Graft-Ack Message (Dense Mode Only) Graft-Ack messages are sent in response to a received Graft message The Graft-Ack is sent only if the interface in which the Graft was received is not the incoming interface for the respective (S,G) (This procedure is done for dense mode groups only.) The format is the same as a Join/Prune message except file:///V|/[%20CISCO%20PRESS%20]/Ciscopress-Developing.Ip.Multicast.Networks/di10xa.htm (22 of 28)09/12/2003 01:12:17 Appendix A-PIM Packet Formats that the value of the message Type field is Candidate-RP-Advertisement Candidate-RP-Advertisements are periodically unicast from the candidate-RPs to the BSR 0123 01234567890123456789012345678901 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |PIM Ver| Type | Reserved | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix-Cnt | Priority | Holdtime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Encoded-Unicast-RP-Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Encoded-Group Address-1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |.| |.| |.| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Encoded-Group Address-n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ PIM Version, Type, Reserved, Checksum Described above Prefix-Cnt file:///V|/[%20CISCO%20PRESS%20]/Ciscopress-Developing.Ip.Multicast.Networks/di10xa.htm (23 of 28)09/12/2003 01:12:17 Appendix A-PIM Packet Formats The number of encoded group addresses included in the message; indicating the group prefixes for which the C-RP is advertising A Prefix-Cnt of \Q0' implies a prefix of 224.0.0.0 with mask length of 4; i.e all multicast groups If the C-RP is not configured with Group-prefix information, the C-RP puts a default value of \Q0' in this field Priority The \QPriority' of the included RP, for the corresponding Encoded-Group Address (if any) highest priority is \Q0' (i.e the lower the value of the \QPriority' field, the higher the priority) This field is stored at the BSR upon receipt along with the RP address and corresponding Encoded-Group Address Holdtime The amount of time the advertisement is valid This field allows advertisements to be aged out Encoded-Unicast-RP-Address The address of the interface to advertise as a Candidate RP The format for this address is given in the EncodedUnicast-Address in 4.1 .IP "Encoded-Group Address-1 n" The group prefixes for which the C-RP is advertising Format previously described file:///V|/[%20CISCO%20PRESS%20]/Ciscopress-Developing.Ip.Multicast.Networks/di10xa.htm (24 of 28)09/12/2003 01:12:17 Appendix A-PIM Packet Formats Differences Between PIMv1 and PIMv2 Packets PIMv1 packets contain the same functional information (albeit with some minor formatting variations) that is carried inside their PIMv2 packet equivalents One key exception is that PIMv1 packets are transmitted using Internet Group Membership Protocol (IGMP) headers, whereas PIMv2 packets use their own assigned protocol (103) In addition, the address encoding method used in PIMv1 is much simpler than the method used in PIMv2, which was extended to permit the use of other protocol address families Finally, some PIMv1 messages were made obsolete when PIMv2 was introduced All these differences are discussed briefly in the following sections PIMv1 Headers All PIMv1 messages (as well as DVMRP and Mtrace messages) ride inside IGMP headers PIMv1 messages are identified by a special PIM Type code (0x14) in the Type field of the IGMP message Therefore, all PIMv1 headers have the following format: 0123 01234567890123456789012345678901 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |PIM Ver| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type There are eight types of IGMP messages currently in use: 0x11 = IGMP Membership Query 0x12 = IGMPv1 Membership Report 0x13 = DVMRP Message 0x14 = PIMv1 Message 0x16 = IGMPv2 Membership Report 0x17 = IGMPv2 Leave Group file:///V|/[%20CISCO%20PRESS%20]/Ciscopress-Developing.Ip.Multicast.Networks/di10xa.htm (25 of 28)09/12/2003 01:12:17 Appendix A-PIM Packet Formats 0x1E = Mtrace Response 0x1F = Mtrace Request Code Codes for specific PIM message types: = Query (basically equivalent to PIMv2 Hello) = Register = Register-Stop = Join/Prune = RP-Reachability (Not used in PIMv2) = Assert = Graft (used in PIM-DM only) = Graft-Ack (used in PIM-DM only) Checksum The checksum is the 16-bit one's complement of the one's complement sum of the entire IGMP message For computing the checksum, the checksum field is zeroed PIM Ver PIM Version number is Reserved set to zero Ignored upon receipt PIMv1 Address Encoding In general, addresses are not encoded in PIMv1 messages Instead, the 32-bit IP address (group, unicast, or source address) is simply used in the message The exception to this convention is in PIMv1 Join/ Prune messages, where source addresses are encoded in the following manner: 0123 file:///V|/[%20CISCO%20PRESS%20]/Ciscopress-Developing.Ip.Multicast.Networks/di10xa.htm (26 of 28)09/12/2003 01:12:17 Appendix A-PIM Packet Formats 01234567890123456789012345678901 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved |S|W|R| Mask Len | Source Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ S The Sparse bit is a bit value, set to for PIM-SM It is used for PIM v.1 compatibility W The WC bit is a bit value If 1, the join or prune applies to the (*,G) entry If 0, the join or prune applies to the (S,G) entry where S is Source Address Joins and prunes sent towards the RP must have this bit set R The RPT-bit is a bit value If 1, the information about (S,G) is sent towards the RP If 0, the information must be sent toward S, where S is the Source Address Mask Len The Mask length is bits The value is the number of contiguous bits left justified used as a mask which describes the address It must be less than or equal to the address length in bits Source Address This address is either an RP address (WC bit = 1) or a source Address (WC bit = 0) When it is a source address, it is file:///V|/[%20CISCO%20PRESS%20]/Ciscopress-Developing.Ip.Multicast.Networks/di10xa.htm (27 of 28)09/12/2003 01:12:17 Appendix A-PIM Packet Formats coupled with the group address to make (S,G) PIMv1 Messages Not Used in PIMv2 In PIMv1, the RP sends RP-Reachability messages down the shared tree to notify all routers that it is still active and reachable The original idea was to have a timer that would expire if these messages were not received periodically Then, a router would send a Join message toward a backup RP Unfortunately, this PIMv1 RP switchover mechanism had problems and never worked properly Therefore, RPReachability messages were dropped from the PIMv2 protocol and are used only in PIMv1 Posted: Tue Mar 21 15:25:14 PST 2000 Copyright 1989 - 2000©Cisco Systems Inc file:///V|/[%20CISCO%20PRESS%20]/Ciscopress-Developing.Ip.Multicast.Networks/di10xa.htm (28 of 28)09/12/2003 01:12:17